[cfe-dev] Where do attributes get merged?

[Robinson, Paul]

> -----Original Message-----
> From: aaron.ballman at gmail.com [mailto:aaron.ballman at gmail.com] On Behalf
> Of Aaron Ballman
> Sent: Wednesday, December 10, 2014 11:50 AM
> To: Robinson, Paul
> Cc: David Majnemer; cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu)
> Subject: Re: [cfe-dev] Where do attributes get merged?
> 
> On Wed, Dec 10, 2014 at 1:32 PM, Robinson, Paul
> <Paul_Robinson at playstation.sony.com> wrote:
> >> -----Original Message-----
> >> From: aaron.ballman at gmail.com [mailto:aaron.ballman at gmail.com] On
> Behalf
> >> Of Aaron Ballman
> >> Sent: Wednesday, December 10, 2014 5:50 AM
> >> To: David Majnemer
> >> Cc: Robinson, Paul; cfe-dev at cs.uiuc.edu Developers (cfe-
> dev at cs.uiuc.edu)
> >> Subject: Re: [cfe-dev] Where do attributes get merged?
> >>
> >> Yes, you're looking for Sema::mergeDeclAttributes. You're also correct
> >> that the current behavior only works when the attributes are on the
> >> same declaration.
> >
> > Awesome, thanks guys. Exactly what I needed.
> >
> >> However, from memory, I don't think that situation of yours should
> >> result in well-formed code. IIRC, the definition must not attempt to
> >> declare new attributes (aside from some keyword-like ones) that do not
> >> also appear on the declaration.
> >
> > Hmm I poked around in online docs for both clang and gcc, I'm not
> finding
> > any statement like that.
> 
> I may have been mis-remembering as well. ;-)
> 
> > Looking at the code, the behavior seems to be:
> > - If we've already seen a definition, a new declaration can't add any
> >   attributes. Except for a couple of special cases.
> > - Otherwise, attributes that are on the old declaration, and are
> inheritable,
> >   are propagated to the new declaration (again with a few special
> cases).
> >
> > The use case for __attribute__((optnone)) is such that having it on the
> > definition but not the declaration would be the normal case.
> 
> GNU-style attributes generally are not definition-only. In fact, I
> believe we only allow that as an extension for attributes known to
> GCC. Since optnone isn't a GCC attribute (at this time), it's not
> technically an extension, but I suspect calling it the "normal case"
> is a bit of a stretch.

Ah, by "normal case" I meant that the usual usage pattern for optnone would
be to attach it to the definition rather than the declaration.  Not that
my proposed behavior for optnone was the "normal case" for attributes in
general.
--paulr

> 
> >  I think it
> > would be reasonable to say that when optnone conflicts with something
> else,
> > the attribute on the definition wins.
> >
> > How does that sound?
> 
> That may be feasible for optnone, but I'm not certain I like it in the
> general sense. Attributes appearing on the definition but not the
> declaration can change the behavior in a substantial way -- for
> instance, a noreturn attribute. Also, this behavior will depend on the
> spelling of the attribute given. A __declspec cannot be added to a
> function definition if it is absent on a function declaration, but the
> reverse isn't true.
> 
> ~Aaron