[cfe-dev] Pragma warning control

[Chris Lattner]

On Jan 9, 2009, at 2:52 PM, Sebastian Redl wrote:
>
> Is there interest in such a feature? I know that GCC's inability to
> control most warnings within a source file causes problems in the  
> Boost
> project from time to time.

Yes, this would be a great feature!  This is definitely worthwhile to  
work on.  I also agree that pragmas are a better way to go than  
attributes.

I wouldn't worry too much about the template issues etc, we can solve  
some of that through extensions to the source location mechanism.

> - We should probably clean up the names of the diagnostics. In the  
> long
> run, this means that the names of the diagnostics become part of the
> public interface of the compiler, which means we can't change them at
> will anymore.

I really think that this problem should be tackled first as a separate  
project.  The "enum names" in DiagnosticKinds.def are intended to be  
unique identifiers, but are really not intended to be "stable".

In addition to warning control in the source code, we also need  
command-line option warning control: we already have some trivial  
options like -Wfloat-equal, -Wunused-macros, -Wundef, etc, but the  
current control over them is adhoc and controlled by C++ code in  
clang.cpp.

Going forward, we need to support more and more of these sorts of  
options in a "roughly" GCC-compatible way, but we also need to support  
harder things like -Wall and -W, which turn on a large set of  
different warnings.

I haven't thought too much about this, but I think it could make sense  
to introduce a notion of hierarchical groups of warning options.  Each  
of these hierarchical groups could be assigned a "stable" name and  
could be controlled by both the command line and the #pragmas.  A  
warning group would have its 1) stable name, 2) list of concrete  
diagnostics included, and 3) list of warning subgroups that it  
includes.  This means that -Wall would just include a bunch of  
subgroups instead of hundreds of individual diagnostics.

This structure may be a bit overwhelming to handle with a .def file,  
if so, we could easily make a tblgen backend to handle this.

What do you think Sebastian?  Do you agree that it would be good to  
tackle this problem before the #pragma version of it?

-Chris