[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