[cfe-dev] Pragma warning control

Douglas Gregor dgregor at apple.com
Mon Jan 12 09:15:27 PST 2009


On Jan 10, 2009, at 4:05 AM, Sebastian Redl wrote:

> Douglas Gregor wrote:
>> Hi Sebastian,
>>
>> On Jan 9, 2009, at 2:52 PM, Sebastian Redl wrote:
>>>
>>> Some concrete issues I can think of:
>>> - Template instantiation would ideally save the warning status  
>>> around
>>> the definition of a template and reintroduce it during  
>>> instantiation;
>>> else you for example disable truncation warnings around the template
>>> definition, but instantiations cause the warning anyway.
>>
>> Yep. This probably means that these pragmas will need to be able to
>> appear wherever (at least) declarations can appear.
>>
>
> What do you mean? In the code? A pragma can appear anywhere.  
> (Although -
> what *is* the effect of a pragma in the middle of an expression?)

Yes, in the AST. We'd have some kind of PragmaWarningDecl/ 
PragmaWarningStmt that can occur wherever a declaration or statement  
can occur, so that the instantiation of this warning/statement could  
perform the appropriate state changes. If we hit a pragma in the  
middle of an expression, we'd just put the pragma's decl/stmt before  
or after the current one and produce a warning to say what we did.

That said, Chris seems to have an idea about how to do this with  
SourceLocations, so I'd like to hear about that.

>>> - Explicitly disabling warnings at the command line could either  
>>> share
>>> status storage with this feature, but then warning(default: id)  
>>> would
>>> enable warnings that were disabled at the command line.  
>>> Alternatively,
>>> the feature could have its own storage, but that means doubling the
>>> required memory.
>>
>> I think warning(default: id) should not change its behavior based on
>> the options on the command line.
>>
>
> That's just a question of the definition of default's behavior. :-) Is
> it defined to
> - Enable the warning (but then it should be called 'enable')

This is the behavior that I would prefer.

	- Doug



More information about the cfe-dev mailing list