[cfe-commits] [PATCH] c++11 type attribute fix
Michael.Han at autodesk.com
Tue Oct 23 15:04:25 PDT 2012
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?
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.
> -----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
> 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 <
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.
More information about the cfe-commits