In feedback from developers using Clang, I have often heard requests such as "please put warning X under a flag" or, more generally, "please put every warning under a flag." I propose that we aim to achieve the latter goal.
I think there are several benefits of us doing this:
(1) Developers can cherry pick which warnings they want to suppress.
(2) Developers can cherry pick which warnings they want escalated to errors.
(3) -W flags provide a locus by which we can match compiler warnings with documentation. Some compiler warnings are more difficult to understand than others, and having an easy way to go from warning to a more thorough explanation would be beneficial to many users.
(4) Covering all warnings under -W flags helps us see what is all the warning behavior in the compiler.
Yesterday, I added a new tool in clang/tools called diagtool, whose goal is both to help analyze our use of diagnostics in clang but in the long term perhaps help in generating documentation for such warnings. Using diagtool, I discovered that only 48% of clang's warnings are currently controllable under a -W flag. While probably the most common warnings are under a flag, I've found that's often not the case (especially when a user files a bug requesting that a warning is placed under a flag). Moreover, I've also observed that as new warnings get added, they often lack -W flags. This can be particularly unfortunate for (legacy) code bases where such warnings pop up many times.
Here is my concrete proposal:
(1) We aim to gradually put all existing warnings under a -W flag. Multiple (related) warnings can be placed under the same -W flag (as they are often done now), but the main idea is to allow users to control these warnings.
(2) We require all new warnings to include a -W flag the moment they are added to Clang. We can enforce this by using diagtool in our tests (e.g., verify that the set of warnings without flags hasn't changed).
Comments? Concerns? Does everyone think this is a good idea, or are there arguments to the contrary?