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 <[email protected]> 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
