[cfe-dev] Duplicate attributes

[Aaron Ballman]

On Mon, Oct 14, 2013 at 9:36 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Mon, Oct 14, 2013 at 5:11 PM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>>
>> To resolve this in a more generic way, I am thinking of table
>> generating some code on the parsed attributes that allows us to ask
>> "given a list of Attr instances, are there any conflicts you can
>> diagnose with this parsed attribute?"  Eg)
>>
>> bool AttributeList::conflictsWith(Sema &S, attr_iterator I,
>> attr_iterator E) const;
>>
>> In this way, when SemaDeclAttr.cpp does common checking for a decl (or
>> statement, type, etc), we can ask the parsed attribute to diagnose any
>> problems it can, generically.
>>
>> There are two situations I am thinking of initially:
>>
>> 1) Duplicate attributes.  This applies pretty generally, and when
>> opt-out is required, we can use table gen to specify the opt-out
>> 2) Mutually exclusive attributes.  This doesn't apply as generally,
>> but is something we already have hand-written support for (cold vs hot
>> attributes), and is missing elsewhere (calling conventions immediately
>> spring to mind).
>>
>> Before I do more concrete work in this direction, do you see any
>> particular problems with this approach?  Or is there a better way you
>> would prefer to see employed?
>
>
> Two things:
> 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.

It would be nice to avoid...

> 2) The C++ restriction is only for attributes *in the same
> attribute-specifier*. So:
>
> [[noreturn, noreturn]] void f(); // ill-formed
> [[noreturn]] [[noreturn]] void f(); // ok
>
> IIRC, we don't preserve enough information into Sema to be able to diagnose
> this there.

We don't seem to preserve enough information, but at the same time,
this could still be a useful warning either way?

~Aaron