[PATCH] D148700: [clang] Add support for “regular” keyword attributes

Wed Jun 7 05:43:02 PDT 2023

aaron.ballman added a comment.

In D148700#4401451 <https://reviews.llvm.org/D148700#4401451>, @rsmith wrote:

> In D148700#4401353 <https://reviews.llvm.org/D148700#4401353>, @jyknight wrote:
>
>> Yes, standard attributes aren't supposed to be used for things which affect the type system (although, we certainly have many, already, which do, since we expose most GCC-syntax attributes also as C++-standard attribute syntax!)
>
> The rule that standard attributes don't affect semantics only applies to attributes specified by the language standard. There is no expectation that vendor attributes avoid such effects. In particular, I'm concerned by this in the description of this change:
>
> In D148700 <https://reviews.llvm.org/D148700>, @rsandifo-arm wrote:
>
>> Really, the “only” thing wrong with using standard attributes is that standard attributes cannot affect semantics.
>
> If the only reason for this patch series is an idea that vendor attributes using `[[...]]` syntax can't affect program semantics, then I think this change is not justified, because vendor attributes using `[[...]]` syntax can and usually do affect program semantics. But the documentation change here makes the point that using a keyword attribute may be as good idea in cases where you would always want compilation to fail on a compiler that doesn't understand the annotation, rather than the annotation being ignored (likely with a warning), so maybe that's reasonable justification for this direction.

That is the reason for this direction -- we have enough instances where people want to add a vendor attribute but it is not safe for other implementations to ignore it (due to ABI, correctness, etc). This feature allows adding the attribute as a keyword which can appear anywhere the attribute can appear. Due to it being expressed as a keyword in source, the other implementations will fail to accept the code, whereas use of a vendor-specified attribute would be (potentially silently) accepted with ill-effects.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148700/new/

https://reviews.llvm.org/D148700