<div dir="ltr">On Wed, Oct 30, 2013 at 6:42 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Instead of hard-coding the attributes which expect a type, is there a<br>

way we can gather that information off the tablegen?  They currently<br>
take a TypeArgument as their first argument, so it should be pretty<br>
simple to modify the attr emitter to provide a list of attributes<br>
which apply.  Then the parser doesn't have hard-coded knowledge about<br>
these one-offs.<br></blockquote><div><br></div><div>Yes, we should, but I didn't want to put too much into a single patch.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


Aside from that, patch LGTM.  Thanks for cleaning this up!<br></blockquote><div><br></div><div>Landed in r193731.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

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