[PATCH] Simplify handling of iboutletcollection and vec_type_hint attributes

[Richard Smith]

On Wed, Oct 30, 2013 at 6:42 PM, Aaron Ballman <aaron at aaronballman.com>wrote:

> Instead of hard-coding the attributes which expect a type, is there a
> way we can gather that information off the tablegen?  They currently
> take a TypeArgument as their first argument, so it should be pretty
> simple to modify the attr emitter to provide a list of attributes
> which apply.  Then the parser doesn't have hard-coded knowledge about
> these one-offs.
>

Yes, we should, but I didn't want to put too much into a single patch.


> Aside from that, patch LGTM.  Thanks for cleaning this up!
>

Landed in r193731.


> ~Aaron
>
> On Thu, Oct 24, 2013 at 6:14 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > Hi,
> >
> > Currently, the iboutletcollection and vec_type_hint attributes are
> parsed by
> > contorting the normal list-of-expressions parsing logic. For
> > iboutletcollection, the "type" is parsed manually, by picking out an
> > identifier followed by an (optional) list of angle-bracketed identifiers,
> > and the latter is ignored. This is needlessly complex; the attached patch
> > modifies them to just parse a type as the attribute argument.
> >
> > The custom handling also breaks parsing for other kinds of attributes
> which
> > *don't* take a type argument; for instance, in
> > "__attribute__((aligned(int)))" we parse and ignore the 'int', and in
> > "__attribute__((aligned(int(1))))" we reject a valid expression because
> we
> > get confused and think it's a type. This is not even bug-compatible with
> > g++, which does the right thing in these cases.
> >
> > Other than fixing bugs, this makes one semantic change: when given a
> > protocol-qualified object type, IBOutletCollectionAttr now stores the
> full
> > type (including the protocol list) where it previously just stored the
> > interface. I've updated the only consumer of this information that I
> could
> > find (in libclang).
> >
> > Please review!
> > Thanks.
> >
> > _______________________________________________
> > cfe-commits mailing list
> > cfe-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131030/f83b2ff9/attachment.html>