[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