[cfe-dev] Pragma warning control

[Chris Lattner]

On Jan 11, 2009, at 6:31 AM, Sebastian Redl wrote:

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

Yes, I think so.  The warning options we already support directly  
control exactly one diagnostic, so we basically have (in tblgen syntax):

// Existing DiagnosticsKinds.def gets converted to tblgen syntax
def pp_macro_not_used : Warning<"macro is not used">;
def warn_floatingpoint_eq : Warning<"comparing floating point with ==  
or != is unsafe">;
...

// New warning group definitions....
def unusedmacros : Group<"unused_macros", [pp_macro_not_used]>;
def floatequal   : Group<"float-equal", [warn_floatingpoint_eq]>;

def readonlysetterattrs
    : Group<"readonly-setter-attrs",  
[warn_objc_property_attr_mutually_exclusive]>;

def formatnonliteral
    : Group<"format-nonliteral", [warn_printf_not_string_constant]>;
def undef : Group<[warn_pp_undef_identifier]>;

def implicitfunctiondeclaration
    : Group<"implicit-function-declaration",  
[warn_implicit_function_decl]>;

etc.  However, going forward there will be other warnings that turn on  
several distinct warnings in the .def file.  This is where having a  
list of warnings is useful.

After We have that, we can start aggregating them together, e.g.:

def all : Group<[undef, implicitfunctiondeclaration, ....]>;

Since tblgen can run arbitrary code, it can reject (or warn about)  
warnings that are not in a warning group etc.  The code generated by  
tblgen could handle the -Wno-foo cases etc.

I'd suggest changing the existing command line option code for -W* in  
clang.cpp to just use a cl::list<std::string> WarningOpts("W", ...).   
Which will just make vector of all the -Wfoo options.  The tblgen  
generated code can then just parse, validate and swizzle that array  
however it wants.

>> 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.)

I can probably tackle this in a couple of weeks.  If you're interested  
at poking at it, I'd suggest taking a look at llvm/include/llvm/ 
Intrinsics.td.  It gets tblgen'd into llvm/include/llvm/ 
Intrinsics.gen.  The code to do this is llvm/utils/TableGen/ 
IntrinsicEmitter.*.

The first step would be to convert the existing diagnostickinds.def  
file to tblgen syntax and generate an Diagnostics.inc file that  
contains the existing views that we get with macro expansion.

-Chris