[PATCH] D51507: Allow all supportable attributes to be used with #pragma clang attribute.

[Richard Smith via cfe-commits]

On Fri, 31 Aug 2018 at 06:35, Aaron Ballman via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> My reasoning is because type attributes have more impact than variable
> attributes and types appear more frequently. Consider using
> address_space where the region includes function definitions. Should
> that apply to the parameters and return types of the function as well
> as the code within the function? Will that be intuitive for users?
>

I think there's actually an easy answer for this: the #pragma clang
attribute mechanism does not support type attributes at all. Calling
conventions, address_space attributes, and the like are not affected by
this patch. So, while we should figure out whether we want to support
injecting type attributes with this pragma, the status quo is that we do
not and cannot.

However... there are some attributes that (for historical reasons, I think)
are not classified as type attribtues, despite clearly being type
attributes in principle, and that this patch would allow usage of with
#pragma clang attribute:

 * ext_vector_type: We handle this as a type attribute but classify it as a
type alias attribute. This just seems to be a bug in the .td file. (We do
*have* type alias handling for it, but that seems wrong to me: all we do
when we see the attribute applied to an alias is to remember the type for
later, and it would make a lot more sense to do that when building the
alias declaration itself rather than pretending the attribute is a
declaration attribute to support this.)

 * mode: We model and handle this as a declaration attribute, but it's
really notionally a type attribute. I expect we model it as a declaration
attribute for GCC compatibility.

(The other type_alias attributes really do apply to the alias and not to
the type, typically transforming the alias declaration into a declaration
of a new type that is different from the original type in some way but that
is canonically equivalent to the original. As such, introducing an
attribute for a block of such aliases seems reasonable and useful.)

I'm going to blacklist those two attributes in this patch. We can decide at
some later time if we want to support type attributes with this pragma or
not, but I think for now we have consensus on the changes herein for all
non-type attributes, and we should go ahead with that part of the change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20180831/ede568f0/attachment.html>