how should AnnotateAttr be inherited?

+Aaron

Tangentially related:

It strikes me our current inheritance behavior for AnnotateAttr (ie, inherit unless already present) makes no sense, as we have no idea what the attribute means or how it should be inherited from one declaration to another. If one declaration has the attribute and a redeclaration has the attribute with a different string, under what circumstances should we drop the old attribute? It seems to me that the only sensible options are “inherit all attributes even if one is already present on the new declaration” (eg, set InheritEvenIfAlreadyPresent) and “never inherit an AnnotateAttr” (eg, make it not be an InheritableAttr).

I have no particular preference between those two; either option seems like it creates some extra hassle for some users of the attribute, and less hassle for others, but the status quo seems wrong. Aaron, what do you think?

+Aaron

Tangentially related:

It strikes me our current inheritance behavior for AnnotateAttr (ie, inherit
unless already present) makes no sense, as we have no idea what the
attribute means or how it should be inherited from one declaration to
another. If one declaration has the attribute and a redeclaration has the
attribute with a different string, under what circumstances should we drop
the old attribute? It seems to me that the only sensible options are
"inherit all attributes even if one is already present on the new
declaration" (eg, set InheritEvenIfAlreadyPresent) and "never inherit an
AnnotateAttr" (eg, make it not be an InheritableAttr).

I have no particular preference between those two; either option seems like
it creates some extra hassle for some users of the attribute, and less
hassle for others, but the status quo seems wrong. Aaron, what do you think?

I agree that the status quo is wrong, but I don't have a strong sense
for whether we should always inherit or never inherit. I kind of feel
that always inheriting but only if there's a difference in attributes
would be in the spirit of the annotate attribute's "this is totally
generic and can mean anything" design. However, I don't think there's
a "clearly correct" behavior here, which also suggests that perhaps it
should be an error (or at least a warning) to try to inherit annotate
attributes with different arguments.

~Aaron

Thank you, isInherited() is what I was looking for :slight_smile:

On the topic of attributes in general, I found it curious that clang completely drops unrecognized attributes and they aren’t made available in any Attr (as far as I could tell), and thus can’t be checked by custom plugins, etc. Do you know if there’s a specific reason for this? Why not keep the original spelling around in something like “UnrecognizedAttr”?

Thank you, isInherited() is what I was looking for :slight_smile:

On the topic of attributes in general, I found it curious that clang
completely drops unrecognized attributes and they aren't made available in
any Attr (as far as I could tell), and thus can't be checked by custom
plugins, etc. Do you know if there's a specific reason for this? Why not
keep the original spelling around in something like "UnrecognizedAttr"?

Personally, I would like to see something along these lines, where the
UnknownAttr (or whatever we call it) wraps as much information as
possible about the parsed attribute, but at a bare minimum keeps the
source location information about where the attribute arguments start
and end and what syntax was used to specify the attribute.

This might be reasonable for declaration attributes, but I'm less
clear on how it would look for attributes which appertain to a type
(whether we build up an AttributedType for it or not) or statements
(do we build an AttributedStmt for it or not), but we'd want to do
something to handle those as well.

~Aaron