<br><br><div class="gmail_quote">Le 8 février 2012 19:34, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Wed, Feb 8, 2012 at 10:17 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>> The rollout of new warnings is largely political.  Believe it or not, many<br>
>> users have complained to use when we roll out new warnings under -Wall.<br>
>>  Such users expect -Wall to have consistent behavior between releases.<br>
><br>
> I could believe it (& I know you mentioned as much when you added<br>
> -Weverything) - but I'm concerned that we end up then catering to the<br>
> lowest common denominator & harm Clang's usefulness on new code bases<br>
> where, if these warnings were adopted from the start, they could be<br>
> quite helpful.<br>
><br>
> (as I mentioned in my reply to Bob - many of the warnings in -Wall are<br>
> prone to the same criticism as -Wcovered-switch-default - they would<br>
> produce a bunch of false positives/violations in any existing code<br>
> base that hadn't been built with the warning all along (-Wswitch<br>
> itself, or -Wparentheses, etc). So how did they get into -Wall to<br>
> begin with? Is the right answer that -Wall is immutable as soon as it<br>
> shipped? I'd imagine that there are users who expect that to be true<br>
> (as you've mentioned) & also users who would be rather surprised by<br>
> this & expect the opposite)<br>
><br>
>> In our case, we observed that many projects we built at Apple violated this<br>
>> warning.  We often push for projects to fix their code, but this was not one<br>
>> that would be worth it.  It's very stylistic.<br>
><br>
> No more stylistic than many other warnings under -Wall (which have the<br>
> luxury of having been there from the start, I know)<br>
><br>
>> We do have a warning group: -Weverything.  That warning group was created so<br>
>> that everyone could opt in to the entire set of warnings, and then turn off<br>
>> the ones they want.<br>
><br>
> Yep - I've been playing with that for some time now trying to use it<br>
> as a way to raise the warning bar in LLVM and to improve the quality<br>
> of warnings (-Wweak-vtable and -Wunreachable-code are a couple you've<br>
> seen me play with - I haven't quite managed to get LLVM totally clean<br>
> (by code fixes & improving the warning quality itself) on either of<br>
> those yet, but WIP)<br>
><br>
>> These issues aside, I don't think -Wcovered-switch-default could be under<br>
>> -Wall either.<br>
><br>
> Fair enough. Don't get me wrong - I do see where you're coming from &<br>
> understand that a 'half closed' warning (warning for the affirmative<br>
> case, but not the negative) is sometimes necessary given the<br>
> limitations of users, etc.<br>
><br>
> I'm also reminded of Chandler's talk at GoingNative last week when he<br>
> mentioned that the -Wparentheses warning didn't used to have the<br>
> inverse (checking that you /don't/ use extra () when you're just doing<br>
> an equality not an assignment) & this was added. But I know it's not a<br>
> perfect analogy because the extra () were already<br>
> deliberately/habitually for -Wparentheses in the first place. Good<br>
> that we could have negative & positive warnings on at the same time by<br>
> default in that case.<br>
><br>
> So to ask a clear question: Should we move -Wswitch from -Wmost to -Wall?<br>
<br>
</div></div>FWIW, I'm for moving -Wswitch to -Wall. This warning produces hundreds<br>
of warnings in ffmpeg and icu (I think), and people who care about<br>
warnings like this are likely to build with -Wall anyway.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>> > Last time I brought up any off-by-default warnings Doug seemed to veto<br>
>> > them. (I'm not sure if he's even seen this warning/has an opinion on<br>
>> > it - I'm a bit concerned that he won't like it once he sees it)<br>
>><br>
>> I don't see the rationale for that.  We have plenty of off-by-default<br>
>> warnings.<br>
><br>
> Good to know - I felt a little alone when I had this discussion with<br>
> Doug on the list about 6 months ago.<br>
><br>
> Thanks,<br>
> - David<br>
><br></div></div></blockquote><div><br>I don't quite see the need to move a warning *away* from -Wall.<br><br>I understand that fixing large code bases is unpractical, I have some such medium large (and oldish) code bases to deal with. However simply tuning the Makefile (-Wno-covered-switch-default) is so simple that I don't quite understand the reluctance here.<br>
<br>It may require a (slight) change of mentality, but the obvious advantage of blacklisting some warnings, is that at least you make explicit what is not checked.<br><br>I don't quite see why Open Source projects would reject a patch to add a few -Wno-XXXX to their makefiles. Certainly this seems trivial and harmless.<br>
<br>--Matthieu <br></div></div>