<div dir="ltr">On Tue, Aug 27, 2013 at 3:16 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Attributes can have a single parameter, as well as multiple (sometimes<br>
optional) arguments.</blockquote><div><br></div><div>What is the distinction you're drawing between parameters and arguments here?</div><div><br></div><div>If you mean the weirdness in the GNU attribute syntax that we sometimes use different parsing rules for the first argument, I don't think modeling that as a fundamentally different kind of argument is the right way to proceed. Instead, we should look at the list of Args when parsing an attribute argument list, to determine how to parse each element.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  However, tablegen currently does not do a very<br>
good job of expressing this, and so the semantic checks have to be<br>
implemented in many different places.<br>
<br>
This patch overhauls the way arguments and parameters are handled in<br>
tablegen.  Specifically, it:<br>
<br>
1) Adds the notion of an explicit parameter to the attribute<br>
definition, instead of implicitly relying on it being the first,<br>
"blessed" type in an argument list.<br>
2) Arguments can now specify that they are optional (by default, all<br>
arguments are mandatory).<br>
3) Updates the tablegen for these new features.  This includes adding<br>
a second attribute constructor which elides the optional arguments<br>
(they can be set later via an explicit setter).<br>
4) Updates the AttributeList to express more information garnered from<br>
the tablegen.<br>
5) Updates the semantic checking for declarations so that it can make<br>
use of this new information on AttributeList and consolidates a bunch<br>
of checking into one function.<br>
<br>
This may seem like the patch is doing a lot of different things, but<br>
in the end, the combination is required in order to make this patch<br>
useful as a unit.  The good news is: subsequent patches consolidating<br>
more error checking should be considerably smaller.  Future error<br>
checking includes: optional parameters and attribute subjects (there<br>
are likely other things we can consolidate as well).<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span></blockquote></div><br></div></div>