================
@@ -177,6 +177,26 @@ static bool isLanguageDefinedBuiltin(const SourceManager
&SourceMgr,
return false;
}
+static bool isReservedAttrName(Preprocessor &PP, IdentifierInfo *II) {
----------------
AaronBallman wrote:
These are great questions!
`__has_cpp_attribute` should return nonzero if Clang "knows" about the
attribute with the current set of compilation flags. e.g., if you would not get
an "unknown attribute ignored" warning for its use.
The library part of the standard reserves attribute names, including in
freestanding mode, but only for purposes of use with `#define` or `#undef`. So
if `__has_cpp_attribute` is zero for a standard attribute with a certain set of
flags, the name is not reserved; otherwise, it is reserved and should be
diagnosed if it's used as the macro name in `#define` or `#undef`.
> Should this one handle the standard versions too?
I don't think so; we expose attributes in older language modes as a conforming
extension (and we fail to issue a `-pedantic` diagnostic for it, which perhaps
is a mistake?). For example, `no_unique_address` is C++20, but we still expose
it in C++11: https://godbolt.org/z/6TWaodjE3
So I think we ultimately want the reserved identifier warning to key off
`__has_cpp_attribute` behavior; if we claim we support the attribute (even as
an extension), library authors should be able to use it, and therefore we
should behave as though it was reserved for purposes of `#define` and `#undef`.
CC @erichkeane for additional opinions
https://github.com/llvm/llvm-project/pull/106036
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
