clang should accept `[[gnu::no_sanitize("...")]]` spelling

[frobtech]

GCC (AFAICT since version 9.1) accepts the no_sanitize attribute in both __attribute__((no_sanitize("..."))) and [[gnu::no_sanitize("...")]] spellings. Clang doesn't accept [[gnu::no_sanitize(...)]] but only [[clang::no_sanitize("...")]] so it's not possible to use modern C++ attribute syntax in source code compatible with both compilers without #ifdefs. Clang should accept both spellings in C++11 attribute syntax.

[shafik]

@erichkeane

[nickdesaulniers]

Re: portability, sometimes it can depend on who added the attribute first. I wonder if GCC supports any clang:: attributes?

[pinskia]

Re: portability, sometimes it can depend on who added the attribute first. I wonder if GCC supports any clang:: attributes?

GCC 15 supports clang::flag_enum and clang::musttail in the clang namespace. (musttail attribute is handled in a different way from other kind attributes so I misread the code a few times).

Note I filed https://gcc.gnu.org/PR118752 for GCC to support clang::no_sanitize as an alias to gnu::no_sanitize.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Roland McGrath (frobtech)

GCC (AFAICT since version 9.1) accepts the `no_sanitize` attribute in both `__attribute__((no_sanitize("...")))` and `[[gnu::no_sanitize("...")]]` spellings. Clang doesn't accept `[[gnu::no_sanitize(...)]]` but only `[[clang::no_sanitize("...")]]` so it's not possible to use modern C++ attribute syntax in source code compatible with both compilers without `#ifdef`s. Clang should accept both spellings in C++11 attribute syntax.