r205226 - Introduced an attribute syntax-neutral method for parsing attribute arguments that is currently being used by GNU and C++-style attributes. This allows C++11 attributes with argument lists to be handled properly, fixing the "deprecated", "type_visibility", and capability-related attributes with arguments.

[Richard Smith]

On Mon, Apr 14, 2014 at 9:21 AM, Aaron Ballman <aaron at aaronballman.com>wrote:

> On Fri, Apr 11, 2014 at 5:40 PM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
> > On Fri, Apr 11, 2014 at 5:38 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> >> Thanks for doing this!
> >>
> >> Looks like this won't reject the ill-formed construct [[deprecated()]].
> >> (Both [[gnu::deprecated()]] and __attribute__((deprecated())) are OK,
> IIRC.)
> >
> > Good point! I'll add that on my TODO list. :-)
>
> Fixed in r206186, but I have a question -- I think
> IsBuiltInOrStandardCXX11Attribute should actually be implemented more
> in terms of the scope name. If there's no scope name, it must be a
> standard C++ attribute. If the scope name is clang, then it is one of
> our built-in attributes and we can reason about it. But anything else
> doesn't qualify. Would you agree with the attached patch?


Seems like this function is really now just checking whether an attribute
can be repeated within the same attribute list? I don't see why that rule
should necessarily apply to all clang:: attributes, and there are some
capability-related attributes where it almost certainly should not apply.

Maybe this should be another tablegen-generated property?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140414/58bf0af7/attachment.html>