[cfe-dev] Warning options table

[Chris Lattner]

On Mar 2, 2009, at 2:04 PM, Sebastian Redl wrote:
>> The "name of the def" becomes the enum name that the C++ code uses,
>> "Warn" is the classification, and the string is the string :).
> Something like this, then?

Yes, exactly.  I'd suggest short names like ExtWarn though instead of  
ExtensionWarning.

>> It should be really easy to convert over our existing .def files to
>> .td files like this (e.g. with a perl script).
> The preprocessor is enough, I think. Just needs a bit of cleanup
> afterwards. The snippet below produces very acceptable code.

Cute!

>> With a declarative way to define the different warning groups, we now
>> need a way to add the diagnostics to the different controlling sets.
>> This can be done by making 'Warn' and friends take an optional list  
>> of
>> warning options they are in.  This would give something like:
>>
>> def pp_macro_not_used : Warn<"macro is not used", [UnusedMacros]>;
>>
>> For hierarchical warning options, the WarningOption could just have a
>> list of things it includes (e.g. -Wall implies -Wunused-macros).

> That's inconsistent. Warnings declare what groups they are in, but
> groups declare what other things they include?

Sure, it would be fine to invert it like we do for diagnostics.

>
> Since we separate warnings from warning options completely, I think it
> would always be best for the options to declare what they enable. Then
> the diagnostic definition doesn't need to care at all about it. In  
> fact,
> we could then put the whole options generation into a separate .td  
> file,
> which appeals to me.

The general approach we use with .td files it to have a master .td  
file that uses the tblgen "include" to pull everything into one big  
file, then have the tblgen backends slice and dice and emit just want  
they want for a particular invocation.

Ted mentioned the desire to keep per-library diagnostic catalogs.  The  
typical way we'd handle this is to have one big .td file that updates  
everything, then have makefile logic that runs tblgen once for each  
library (to emit the .inc file for each library).  If any of the .td  
inputs have changed, tblgen is rerun for each library, but the .inc  
file is only overwritten (triggering recompilation of .cpp files that  
include it) if the contents of the .inc file have changed.  This is  
what we do with the LLVM code generator .td files and it works very  
elegantly.

>>> I have to
>>> do all the parsing myself, including special treatment of -Werror.
>>
>>
>> I am not 100% certain, but I think that if you declare an cl::opt  
>> that
>> exactly matches -Werror, I think it will get preference to -W as a
>> prefix option.
>>
> I'll just have to try it.

I tried it today for the "-m" prefix option and it worked.

>>> Ideas? Chris? Can I specify the options separately and still  
>>> easily walk
>>> them in order?
>>
>> cl::list can also tell you the position on the command line that each
>> option was specified.
> Which is interesting if we want options intermixed with source files  
> to
> only affect the source files they come before, e.g.
>
> # Compile the first file with -Wall, but the second with no warnings
> except -Wimplicit
> clang -c -Wall foo.c -Wno-all -Wimplicit bar.c -Wi-am-ignored
>
> If we don't want this, I only care about relative order.

Right, warning options don't work this way: "the last one wins", so  
you just care about relative ordering.

-Chris