[cfe-commits] [PATCH] c++11 type attribute fix

Michael Han Michael.Han at autodesk.com
Tue Oct 23 18:47:55 PDT 2012


Thanks for the explanation and correction of test case! Now I understand the word "appertain" is for syntactic relationship thus checks should be done during parsing :)

Cheers
Michael
-----Original Message-----
From: Eli Friedman [mailto:eli.friedman at gmail.com] 
Sent: Tuesday, October 23, 2012 5:10 PM
To: Michael Han
Cc: cfe-commits at cs.uiuc.edu
Subject: Re: [cfe-commits] [PATCH] c++11 type attribute fix

On Tue, Oct 23, 2012 at 4:38 PM, Michael Han <Michael.Han at autodesk.com> wrote:
> Hi Eli,
>
>> But something has already gone wrong if in "[[foo]] int [[foo]] x;", both attributes end up in the same attribute list.
>
> I think attributes that appear before declaration specifier will be taken and merged in the attribute list of the declaration specifier when declaration specifier is parsed; that's why it seems to me using source location is the only way to tell if an attribute is part of declaration specifier, or taken from somewhere else. Do you think this is a bug in parser that should be fixed? Maybe, in case of "[[foo]] int [[foo]] x", there should be two attribute list one associated with declaration specifier and the other associated with the declarator id?

I think the key point here is that whether we should attempt to apply an attribute to a declaration or to a type is purely syntactic, and therefore should be handled by the parser.  If we're trying to apply the attribute to the decl in "int [[carries_dependency]] x;", we've already lost.

Also, your "float also_correct(int x [[carries_dependency]]) [[carries_dependency]];" testcase is in fact not valid per the standard; an attribute specified after the parameter list of a function applies to the function type, not the declaration.  The correct way to write it is "float also_correct [[carries_dependency]] (int x [[carries_dependency]]) ;".

>> I don't understand why you're special-casing AT_CarriesDependency.
> This attribute can't be applied to types so I am emitting an error message that is different than default error message (unknown attributes ignored); thus I am special casing it. My understanding is in general any type attributes that can be handled (either applying it to types, or emitting customized error message) should be special cased.

There isn't any reason to special-case every declaration attribute with a different diagnostic about how it doesn't apply to types, is there?

-Eli




More information about the cfe-commits mailing list