[cfe-dev] Pragma warning control

[Sebastian Redl]

Chris Lattner wrote:
> On Jan 9, 2009, at 2:52 PM, Sebastian Redl wrote:
>
>> - 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".

So, we define separate stable names?

>
> 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 sounds like a good idea.

> 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?

Yes, we definitely need to tackle this first, since tackling it after
would mean rewriting the whole pragma stuff. I have no idea how tblgen
works, but I agree that the preprocessor is probably not powerful
enough. (Well, it is powerful enough, but the definition would be close
to unreadable.)

Sebastian