[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