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

[Michael Han]

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?

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?

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

On Mon, Oct 22, 2012 at 9:40 AM, Michael Han <Michael.Han at autodesk.com> wrote:
> Ping with updated patch against TOT.
>
> Michael
> -----Original Message-----
> From: Michael Han
> Sent: Thursday, October 18, 2012 11:48 AM
> To: 'cfe-commits at cs.uiuc.edu'
> Subject: [PATCH] c++11 type attribute fix
>
> Hi,
>
> This patch enables Clang to apply C++11 attributes present after declaration specifiers to types instead of declarators, and warn on attributes that appear at wrong place (like carries_dependency which can't be applied to types). Please review, thanks!

+      if (isDeclSpec && declSpecLoc.isValid() && declSpecLoc < 
+ attr.getLoc())

You can't use "<" on source locations like this; it provides an ordering, but that ordering isn't source order.

More generally, the whole "try to apply to a type, fall back to a decl" thing is specific to gcc attribute syntax; we shouldn't be doing that for C++11 attributes regardless of whether the attribute in question is defined in the C++11 standard.

-Eli