[llvm-dev] Miscellaneous warnings in code using Visual Studio

[David Blaikie via llvm-dev]

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>