[clang] [Clang][Parser] Accept P2741R3 (static_assert with user-generated message) in C++11 as an extension (PR #102044)
Nikolas Klauser via cfe-commits
cfe-commits at lists.llvm.org
Tue Aug 6 06:25:35 PDT 2024
================
@@ -671,10 +671,8 @@ static void InitializeCPlusPlusFeatureTestMacros(const LangOptions &LangOpts,
LangOpts.CPlusPlus23 ? "202211L"
: LangOpts.CPlusPlus17 ? "201603L"
: "200907");
- Builder.defineMacro("__cpp_static_assert", LangOpts.CPlusPlus26 ? "202306L"
- : LangOpts.CPlusPlus17
- ? "201411L"
- : "200410");
+ // C++17 / C++26 static_assert backported
+ Builder.defineMacro("__cpp_static_assert", "202306L");
----------------
philnik777 wrote:
> https://eel.is/c++draft/cpp.predefined has two styles of predefined macros. Ones where there is normative text explaining what the macro has to expand to, and others where it simply lists a value in a table. Nothing in that subclause says "shall be defined as" for the values in the table. It just says the _names_ shall be defined.
Hmm, true. The library version seems less ambiguous, since there it's in the synopsis as `#define __cpp_lib_whatever <some_number>L`.
> Probably one Core issue and one Library issue.
Sounds good. Who should file them?
> Huh? The idiomatic use is `#if defined(__cplusplus) && __cpp_whatever >= 201907L`, so bumping to a later revision is not a breaking change. It's of course possible for a user to test using `==` or some other approach, but they're using the feature testing macro incorrectly at that point.
I'm more thinking of stuff like this: https://godbolt.org/z/qzaMaP4sW.
https://github.com/llvm/llvm-project/pull/102044
More information about the cfe-commits
mailing list