[PATCH] Simplify handling of iboutletcollection and vec_type_hint attributes

[Aaron Ballman]

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.

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

~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
>