On Oct 4, 2011, at 9:27 AM, David Blaikie wrote: > Could/should we support -Wno-* by default anyway? I mean if we don't > have the warning it is certainly not on. > (on the other hand, as a user I wouldn't mind knowing if I'm passing > useless flags. Except when I'm trying to use multiple compilers and > turn something off in one which isn't present in the other. Minor > convenience to have that silently(ish) accepted on the no supporting > compiler)
Hi David, Numerous people have requested that all warnings can be placed under a -W flag, and allow them to selectively turn them on or off. I'll try and summarize why I think this is a critical feature. First off, warnings are warnings. They are "added value." If a warning was truly so sacred that you cannot turn it off, in my opinion it should be an error. If you have the ability to enable a warning, you should also be able to turn it off. Second, I think placing all warnings under -W flags and supporting -Wno- for all warnings enables several key workflows: (1) You can use -Wall or -Weverything, and selectively disable a warning. This enables the workflow of "give me all warnings" and then turn off a few, rather than going the other way of enabling warnings in piecemeal. (2) You can build your code with -Werror, and not be afraid to adopt a newer version of Clang. If you adopt a newer version of Clang and get a new warning, you have the option to turn off the warning (temporarily), allowing your code to still build but giving you time to fix your code. (3) One person's warning is another person's noise. Warnings are inherently subjective. Which warning do we not allow -Wno- to support? I don't think such discussions would bear much fruit. Whenever we added a new warning, we'd have to consider whether or not to support -Wno. I also don't see how not supporting -Wno on specific warnings would provide any benefit. (4) Warnings can be categorized with -W flags. Users can key off documentation based on flag names. Without a flag, all they have is the warning text, which is subject to change. Warning flags also give us a way to systematically measure when building projects which warnings fire frequently, which ones are useful, etc. I can't overstate the importance of all of these, but (2) comes up very frequently for us at Apple. Without that ability, it would be *very* difficult for us to roll out new warnings. (3) is also a big concern. I've seen some developers who love warnings, and others who want to suppress whole classes of warnings because they find them annoying. - Ted
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
