<div dir="ltr">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).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 12, 2021 at 9:29 AM Paul C. Anagnostopoulos <<a href="mailto:paul@windfall.com">paul@windfall.com</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">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.<br>
<br>
I could always enable it just for a build of my code, then disable it 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 - 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)<br>
<br>
</blockquote></div>