<div dir="ltr">On Mon, Oct 14, 2013 at 5:11 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">To resolve this in a more generic way, I am thinking of table<br>
generating some code on the parsed attributes that allows us to ask<br>
"given a list of Attr instances, are there any conflicts you can<br>
diagnose with this parsed attribute?"  Eg)<br>
<br>
bool AttributeList::conflictsWith(Sema &S, attr_iterator I,<br>
attr_iterator E) const;<br>
<br>
In this way, when SemaDeclAttr.cpp does common checking for a decl (or<br>
statement, type, etc), we can ask the parsed attribute to diagnose any<br>
problems it can, generically.<br>
<br>
There are two situations I am thinking of initially:<br>
<br>
1) Duplicate attributes.  This applies pretty generally, and when<br>
opt-out is required, we can use table gen to specify the opt-out<br>
2) Mutually exclusive attributes.  This doesn't apply as generally,<br>
but is something we already have hand-written support for (cold vs hot<br>
attributes), and is missing elsewhere (calling conventions immediately<br>
spring to mind).<br>
<br>
Before I do more concrete work in this direction, do you see any<br>
particular problems with this approach?  Or is there a better way you<br>
would prefer to see employed?<br></blockquote><div><br></div><div>Two things:</div><div>1) What you're proposing sounds O(n^2). While that's unlikely to be a problem in practice, it'd be nice to avoid.</div><div>
2) The C++ restriction is only for attributes *in the same attribute-specifier*. So:</div><div><br></div><div>[[noreturn, noreturn]] void f(); // ill-formed</div><div>[[noreturn]] [[noreturn]] void f(); // ok</div><div><br>
</div><div>IIRC, we don't preserve enough information into Sema to be able to diagnose this there.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Thanks!<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Sun, Oct 6, 2013 at 9:01 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
><br>
> On 5 Oct 2013 16:15, "Aaron Ballman" <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>> wrote:<br>
>><br>
>> I noticed that we have a diagnostic "err_repeat_attribute", but<br>
>> currently only vecreturn is making use of it.<br>
>><br>
>> This seems like it is something we could generalize across attributes<br>
>> relatively easily, but there appears to be no documentation (even in<br>
>> the C++ standard) as to whether duplicate attributes are acceptable or<br>
>> not for any given attribute.<br>
><br>
> For a standard c++11 attribute, there is usually (always?) a restriction<br>
> that the attribute cannot be repeated in the same attribute-specifier.<br>
><br>
>> As best I can tell, most attributes should diagnose a duplicate on the<br>
>> same subject.  The exceptions, as best I can gather, are:<br>
>><br>
>> alloc_size<br>
>> format_arg<br>
>> nonnull<br>
>> ownership_holds<br>
>> ownership_returns<br>
>> ownership_takes<br>
>> argument_with_type_tag<br>
>> pointer_with_type_tag<br>
>><br>
>> Basically, anything which allows you to specify an argument index as<br>
>> an attribute parameter seems like it could have a duplicate attribute.<br>
>><br>
>> Would it make sense to add a generalized duplicate attribute test in<br>
>> SemaDeclAttr that emits an error when a duplicate is found, except for<br>
>> the above cases?<br>
>><br>
>> ~Aaron<br>
</div></div></blockquote></div><br></div></div>