[PATCH] Attribute parameters and arguments

[Aaron Ballman]

Now that the notion of a parameter has been removed from attribute
arguments, this is the original patch (sans parameter functionality)
rebased against ToT.  It automates the error checking for the number
of attribute args expected vs given.

~Aaron

On Tue, Aug 27, 2013 at 10:00 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
> On Tue, Aug 27, 2013 at 7:08 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>> On Tue, Aug 27, 2013 at 3:33 PM, Aaron Ballman <aaron at aaronballman.com>
>> wrote:
>>>
>>> On Tue, Aug 27, 2013 at 6:27 PM, Richard Smith <richard at metafoo.co.uk>
>>> wrote:
>>> > On Tue, Aug 27, 2013 at 3:16 PM, Aaron Ballman <aaron at aaronballman.com>
>>> > wrote:
>>> >>
>>> >> Attributes can have a single parameter, as well as multiple (sometimes
>>> >> optional) arguments.
>>> >
>>> >
>>> > What is the distinction you're drawing between parameters and arguments
>>> > here?
>>>
>>> Parameters are used by GNU-only attributes, arguments everywhere else.
>>>  The distinction is required so that we can properly handle error
>>> reporting when parameters and arguments are both required for the
>>> attribute.
>>>
>>> > 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.
>>>
>>> I do mean that weirdness, but this has very little to do with parsing.
>>>  The parsing logic is identical to its previous state, except instead
>>> of looking for things which don't have params and bailing out, we look
>>> for the much smaller list of things which do have params and include
>>> them.
>>>
>>> I dislike the notion of looking at the first argument in the list and
>>> essentially guessing whether it's a parameter.
>>
>>
>> It would not be a guess. We would look at the kind of the argument, and
>> parse an entity of that kind.
>>
>>> That makes semantic
>>> checking basically impossible to generalize because we don't know
>>> whether we should be looking for a parameter or not.  FWIW, this
>>> caused (what I think are) bugs that I rectified in the test cases once
>>> the logic was made more explicit.
>>
>>
>> The parameter/argument thing is a bogus distinction that we made up. Under
>> the GNU syntax, the first argument sometimes has different parsing rules,
>> that's all. The right thing to do is to change AttributeList to represent
>> the "parameter" as just another argument, not to make the distinction here
>> more ingrained.
>
> Okay, after discussing it a bit on IRC, I think it's a good idea to
> drop the param distinction and try to consolidate the param with the
> args.  I'll do some exploration on the subject.  In the meantime, I
> may also try to back out the param-specific changes from my patch and
> resubmit if I can get the error reporting reasonable.
>
> My biggest question is: are you okay with the approach I took in
> AttributeList for obtaining information from the tablegen?
>
> ~Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AttrParamArgs3.patch
Type: application/octet-stream
Size: 46029 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130909/6ecbcfc4/attachment.obj>