<div dir="ltr">In LLDB, we've been moderately aggressive at fixing warnings for MSVC.<div><br></div><div>The particular example given (`assert(uint16_t + uint16_t >= size_t)`)
is almost certainly harmless, especially since it's in an assertion.</div><div><br></div><div>I have, however, spent a lot of time chasing bugs (in other projects) that could have been found immediately by enabling signed/unsigned comparison warnings. As a result, I'm particularly uncomfortable ignoring those. I've developed fluency in the integral conversion rules, but I'm not sure every C++ programmer would immediately recognize where the signed value arises given that the expression involves three unsigned values. And it's exactly those kinds of implicit conversions that lead to surprising bugs, and it's why it's a reasonable warning to pay attention to.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 12, 2021 at 11:00 AM via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yeah, periodically I contemplate doing some patches to reduce the noise<br>
from MSVC, but the annoyance has never risen to the level of deciding<br>
to act on it.<br>
There is one module whose contents are completely conditionalized out<br>
on Windows, but I think that produces a linker warning rather than a<br>
compiler warning, so I wouldn't expect Werror to turn that into a hard<br>
error.<br>
--paulr<br>
<br>
> -----Original Message-----<br>
> From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> On Behalf Of Chris<br>
> Tetreault via llvm-dev<br>
> Sent: Tuesday, January 12, 2021 1:30 PM<br>
> To: Paul C. Anagnostopoulos <<a href="mailto:paul@windfall.com" target="_blank">paul@windfall.com</a>>; David Blaikie<br>
> <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>>; LLVM Dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> Subject: Re: [llvm-dev] Miscellaneous warnings in code using Visual Studio<br>
> <br>
> As a fellow Visual Studio user, I feel your pain. However, trying to fix<br>
> these warnings is a losing battle. Most LLVM developers do not use Visual<br>
> Studio, so my experience tells me that new warnings will be added faster<br>
> than you can fix them. This is not a indictment of the community; it's<br>
> just that there are so many compilers out there and they all have<br>
> different warnings. Being werror clean across compilers is just not<br>
> manageable.<br>
> <br>
> As the code owner of tablegen, it may be worth it to get your bit of the<br>
> codebase close to being werror clean just for your personal productivity.<br>
> I don't know how hard that would be, some parts of the codebase are pretty<br>
> gross in MSVC.<br>
> <br>
> Thanks,<br>
> Christopher Tetreault<br>
> <br>
> -----Original Message-----<br>
> From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> On Behalf Of Paul C.<br>
> Anagnostopoulos via llvm-dev<br>
> Sent: Tuesday, January 12, 2021 9:26 AM<br>
> To: David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>><br>
> Cc: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> Subject: [EXT] Re: [llvm-dev] Miscellaneous warnings in code using Visual<br>
> Studio<br>
> <br>
> The problem with not fixing them is that I cannot enable WERROR. So<br>
> warnings in my own code might zoom by unseen and then bust the build, as<br>
> happened the other day. Of course, it's possible that warning was one<br>
> produced by the build's compiler but not by Visual Studio's.<br>
> <br>
> I could always enable it just for a build of my code, then disable it<br>
> again.<br>
> <br>
> <br>
> At 1/12/2021 12:17 PM, David Blaikie wrote:<br>
> >If they prove to be good cleanup/improvements to the code in general -<br>
> but we don't try too hard to be -Werror clean on every compiler, mostly<br>
> just self-hosted clang. The line is fuzzy - if a warning isn't /too/ bad<br>
> (ie: doesn't require extreme contortions to the code to address the<br>
> warning) then fixing instances seems ok. If it's unhelpful (eg: a warning<br>
> has a high false positive rate and/or clang's equivalent warning is more<br>
> nuanced and avoids the need to touch false positives) we may disable<br>
> warnings in LLVM. (this doesn't address the issue of warnings in LLVM's<br>
> public headers - not every downstream consumer of LLVM is going to disable<br>
> the same set of warnings, so sometimes it's necessary to do some warning<br>
> cleanup even for undesirable warnings)<br>
> <br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://urldefense.com/v3/__https://lists.llvm.org/cgi-" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.llvm.org/cgi-</a><br>
> bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!v9R-<br>
> rlLFi_Ghr5_kcghnnBpBD15R43Nl8Gkw6cXT5D0796AN5sKYlukrjHDP-Q5dyw$<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://urldefense.com/v3/__https://lists.llvm.org/cgi-" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.llvm.org/cgi-</a><br>
> bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!v9R-<br>
> rlLFi_Ghr5_kcghnnBpBD15R43Nl8Gkw6cXT5D0796AN5sKYlukrjHDP-Q5dyw$<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>