[cfe-dev] specifying warning groups with TableGen

[Ted Kremenek]

Sebastian did a great job prototyping some initial support for  
"warning groups" in Warnings.cpp:

#define DIAGS(a) a, (sizeof(a) / sizeof(a[0]))
// These tables will be TableGenerated later.
// First the table sets describing the diagnostics controlled by each  
option.
static const diag::kind UnusedMacrosDiags[] =  
{ diag::pp_macro_not_used };
static const diag::kind FloatEqualDiags[] =  
{ diag::warn_floatingpoint_eq };
static const diag::kind ReadOnlySetterAttrsDiags[] = {
  diag::warn_objc_property_attr_mutually_exclusive
};
static const diag::kind FormatNonLiteralDiags[] = {
  diag::warn_printf_not_string_constant
};
static const diag::kind UndefDiags[] =  
{ diag::warn_pp_undef_identifier };
static const diag::kind ImplicitFunctionDeclarationDiags[] = {
  diag::ext_implicit_function_decl, diag::warn_implicit_function_decl
};

Following up on the recent addition of TableGen files that specify the  
list of Clang warnings, I wanted to write another TableGen backend  
that generates these tables from our new warnings .td files.  Before  
we do this, I think we need to converge on a format of how to specify  
such warning groups.

In previous messages, I advocated for making membership in groups  
declarative.  That is, when we define a warning in a TableGen file,  
the warning itself denotes the warning groups for which it is a  
member.  If we decide to pursue this approach, all that is left is to  
decide the syntax in the warnings .td files.

Here is an example warning from our .td files:

def err_field_designator_unknown : Error<
  "field designator %0 does not refer to any field in type %1">;

This syntax is beautiful in that it is declarative, simple, and  
succinct.  When adding the notion of warning groups, it would be great  
to keep these three features.  I'm thinking of the following syntax:

def error_name : Error<"error string", [ list of groups ]>

We can (I believe) make the list of groups optional by having it  
default initialized to an empty list. The list itself will be a list  
of values for explicitly declared groups instead of strings; this way  
the TableGen backend can detect errors where a group name was  
accidentally mistyped.

Thoughts?  I think this would be really easy to implement as a  
TableGen backend (I'm volunteering to do it).  I wanted to vet this  
approach with everyone, however, before going ahead with it.

Ted