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

Richard Smith richard at metafoo.co.uk
Tue Oct 23 16:49:57 PDT 2012


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?

For full source fidelity, we should have a list of attributes for
*each* decl-specifier in a decl-specifier-seq. We should not muddle
these with the initial attributes, which appertain to the declarators,
and not to the decl-specifiers. For instance:

[[a]] const [[b]] int [[c]] unsigned [[d]] var1 [[e]], var2;

[[a]] appertains to 'var1' and 'var2'. [[b]] appertains to the
'const'. [[c]] appertains to the 'int'. [[d]] appertains to the
'unsigned'. [[e]] appertains just to 'var1'.

However, we could punt on a lot of this, since we do not yet support
any attributes which appertain to decl-specifiers -- we could reject
C++11 attributes which appertain to decl-specifiers in the parser for
now -- though we will probably eventually need some way to represent
them.

>> 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.
>
> Michael
> -----Original Message-----
> From: Eli Friedman [mailto:eli.friedman at gmail.com]
> Sent: Tuesday, October 23, 2012 3:31 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 3:04 PM, Michael Han <Michael.Han at autodesk.com> wrote:
>> Hi Eli,
>>
>> Thank you for the review!
>>
>> I was using "<" to differentiate case '[[foo]] int x' from 'int [[foo]] x'. Is there a reliable way to tell from SourceLocation that one construct appears before the other?
>
> SourceManager::isBeforeInTranslationUnit .  But something has already gone wrong if in "[[foo]] int [[foo]] x;", both attributes end up in the same attribute list.
>
>> Regarding "try to apply to a type, fall back to a decl": the patch tries to avoid that by having all C++11 attributes that apply to types get processed in processTypeAttrs, so C++11 attributes are either get handled directly (like carries_dependency), or warns on default case; there is no fall back to declaration. Do you think this strategy is in general valid and if so any suggestions on the best place to handle C++11 attributes that applies to types?
>
> I don't understand why you're special-casing AT_CarriesDependency.
> Otherwise, that makes sense.
>
> -Eli
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits




More information about the cfe-commits mailing list