llvm dev - Jan 2021 - Miscellaneous warnings in code using Visual Studio

The problem with not fixing them is that I cannot enable WERROR. So warnings in
my own code might zoom by unseen and then bust the build, as happened the other
day. Of course, it's possible that warning was one produced by the
build's compiler but not by Visual Studio's.

I could always enable it just for a build of my code, then disable it again. 


At 1/12/2021 12:17 PM, David Blaikie wrote:
>If they prove to be good cleanup/improvements to the code in general - but
we don't try too hard to be -Werror clean on every compiler, mostly just
self-hosted clang. The line is fuzzy - if a warning isn't /too/ bad (ie:
doesn't require extreme contortions to the code to address the warning) then
fixing instances seems ok. If it's unhelpful (eg: a warning has a high false
positive rate and/or clang's equivalent warning is more nuanced and avoids
the need to touch false positives) we may disable warnings in LLVM. (this
doesn't address the issue of warnings in LLVM's public headers - not
every downstream consumer of LLVM is going to disable the same set of warnings,
so sometimes it's necessary to do some warning cleanup even for undesirable
warnings)

Yep, it's a tradeoff to be sure. I'd recommend, if possible,
self-hosting
(using clang to build your development clang) - but otherwise, yes, fixes
to other compiler warnings are welcome but in some cases it may be
desirable to disable  a warning instead (& realize this kind of thing will
regress easily due to other people's contributions since they aren't
using
MSVC).

On Tue, Jan 12, 2021 at 9:29 AM Paul C. Anagnostopoulos <paul at
windfall.com>
wrote:
> The problem with not fixing them is that I cannot enable WERROR. So
> warnings in my own code might zoom by unseen and then bust the build, as
> happened the other day. Of course, it's possible that warning was one
> produced by the build's compiler but not by Visual Studio's.
>
> I could always enable it just for a build of my code, then disable it
> again.
>
>
> At 1/12/2021 12:17 PM, David Blaikie wrote:
> >If they prove to be good cleanup/improvements to the code in general -
> but we don't try too hard to be -Werror clean on every compiler, mostly
> just self-hosted clang. The line is fuzzy - if a warning isn't /too/
bad
> (ie: doesn't require extreme contortions to the code to address the
> warning) then fixing instances seems ok. If it's unhelpful (eg: a
warning
> has a high false positive rate and/or clang's equivalent warning is
more
> nuanced and avoids the need to touch false positives) we may disable
> warnings in LLVM. (this doesn't address the issue of warnings in
LLVM's
> public headers - not every downstream consumer of LLVM is going to disable
> the same set of warnings, so sometimes it's necessary to do some
warning
> cleanup even for undesirable warnings)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210112/8c0565cf/attachment.html>

As a fellow Visual Studio user, I feel your pain. However, trying to fix these
warnings is a losing battle. Most LLVM developers do not use Visual Studio, so
my experience tells me that new warnings will be added faster than you can fix
them. This is not a indictment of the community; it's just that there are so
many compilers out there and they all have different warnings. Being werror
clean across compilers is just not manageable.

As the code owner of tablegen, it may be worth it to get your bit of the
codebase close to being werror clean just for your personal productivity. I
don't know how hard that would be, some parts of the codebase are pretty
gross in MSVC.

Thanks,
   Christopher Tetreault

-----Original Message-----
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Paul C.
Anagnostopoulos via llvm-dev
Sent: Tuesday, January 12, 2021 9:26 AM
To: David Blaikie <dblaikie at gmail.com>
Cc: llvm-dev at lists.llvm.org
Subject: [EXT] Re: [llvm-dev] Miscellaneous warnings in code using Visual Studio

The problem with not fixing them is that I cannot enable WERROR. So warnings in
my own code might zoom by unseen and then bust the build, as happened the other
day. Of course, it's possible that warning was one produced by the
build's compiler but not by Visual Studio's.

I could always enable it just for a build of my code, then disable it again.


At 1/12/2021 12:17 PM, David Blaikie wrote:
>If they prove to be good cleanup/improvements to the code in general - but
we don't try too hard to be -Werror clean on every compiler, mostly just
self-hosted clang. The line is fuzzy - if a warning isn't /too/ bad (ie:
doesn't require extreme contortions to the code to address the warning) then
fixing instances seems ok. If it's unhelpful (eg: a warning has a high false
positive rate and/or clang's equivalent warning is more nuanced and avoids
the need to touch false positives) we may disable warnings in LLVM. (this
doesn't address the issue of warnings in LLVM's public headers - not
every downstream consumer of LLVM is going to disable the same set of warnings,
so sometimes it's necessary to do some warning cleanup even for undesirable
warnings)
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev