[cfe-dev] Warning options table

Cédric Venet cedric.venet at laposte.net
Mon Mar 2 15:20:08 PST 2009


Ted Kremenek a écrit :
> On Mar 2, 2009, at 2:04 PM, Sebastian Redl wrote:
>
>   
>>> def pp_macro_not_used : Warn<"macro is not used">;
>>>
>>> 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?
>>
>> // Base of all diagnostics
>> class Diagnostic<string text> {
>>  string Text = text;
>> }
>>
>> // Hard errors
>> class Error<string text> : Diagnostic<text>;
>>
>> // Notes, usually contain additional info for a previous diagnostic
>> class Note<string text> : Diagnostic<text>;
>>
>> // Warnings, things that are not illegal, but worrisome. Displayed by
>> default,
>> // but can be ignored or made into errors with switches.
>> class Warning<string text> : Diagnostic<text> {
>>  string Mapping = "warning";
>> }
>>
>> // Warnings about extensions, i.e. non-portable code. Ignored by  
>> default,
>> // can be turned into warnings with switches.
>> class Extension<string text> : Warning<text> {
>>  let Mapping = "ignore";
>> }
>>
>> // Warnings in extension code. Displayed by default. The difference to
>> normal
>> // warnings is that these are affected by ErrorOnExtensions.
>> class ExtensionWarning<string text> : Warning<text>;
>>     
>
> This looks very reasonable to me, although we might want to further  
> subclass into "SemaWarning" (subclassing Warning) and  
> "SemaError" (subclassing Error) so we can partition the warnings for  
> the individual libraries.
>   

It may be easier to use a multiple let? I don't remenber the syntax 
exactly but something like that:

let lib= "sema" in
<many declaration>

it would avoid the need to have type of warning*number of library class 
explosion... (now that I think about it, using multiclass could probably 
do the trick)

> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>   




More information about the cfe-dev mailing list