On Fri, 31 Aug 2018 at 06:35, Aaron Ballman via cfe-commits < cfe-commits@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.
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
