[clang] [clang] Add support for [[clang::diagnose_if(...)]] and [[clang::enable_if(...)]] syntax (PR #225900)
via cfe-commits
cfe-commits at lists.llvm.org
Wed Sep 23 15:47:26 PDT 2026
higher-performance wrote:
@ojhunt note that this is already the exact same problem `[[gnu::deprecated]]` faced, and handled just fine:
```
void f3(void) [[gnu::deprecated]] {} // warning: attribute 'gnu::deprecated' ignored, because it cannot be applied to a type [-Wignored-attributes]
auto g3(void) [[gnu::deprecated]] -> void {} // warning: attribute 'gnu::deprecated' ignored, because it cannot be applied to a type [-Wignored-attributes]
auto g5(void) -> void [[gnu::deprecated]] {} // error: 'gnu::deprecated' attribute cannot be applied to types
```
If we assume we want the `[[...]]` syntax, it seems only logical that it could and should receive the exact same treatment.
So are you asking why the `[[...]]` syntax is better than the `__attribute__` syntax? I would say for the same reason(s) that that is the case universally, including for all the other attributes already supported with that syntax. Off the top of my head (I may be missing some), just a few:
- Using a standard syntax rather than a nonstandard syntax allows it to compile with other compilers openly, rather than having to hide it behind a macro that users then have to navigate to the definition of in order to understand.
- The standard syntax is a lot friendlier to basic text-based tools (regexes, lexers, etc.) as they can skip everything inside them without knowing what they mean.
- Forcing users to put these behind a macro means parsers can understand the file without having to read the `#include`s or preprocessing macros. (Lots of examples here, but the most well-known is probably tree-sitter.)
- Rudimentary parsers/code generators/etc. don't understand nonstandard syntax.
- It's just so much easier to read. The underscores are ugly and distracting.
>From my perspective, therefore, the question is what is there to lose from treating this similarly to `gnu::deprecated`, `gnu::always_inline`, etc.? There are so many upsides and no real downsides I can see.
https://github.com/llvm/llvm-project/pull/225900
More information about the cfe-commits
mailing list