[clang] [Clang][Parser] Accept P2741R3 (static_assert with user-generated message) in C++11 as an extension (PR #102044)

[Aaron Ballman via cfe-commits]

================
@@ -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");
----------------
AaronBallman wrote:

> I'm not exactly sure what's ambiguous here. You say yourself that it specifies what the value should be for a given standards version.

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.

> Anyways, since we seem to agree that implementations should be allowed to define them to some higher number, I'm not sure it makes a ton of sense to do anything other than filing an issue. But where should it be filed? Is that core wording or library? Both? Neither?

Probably one Core issue and one Library issue.

Worth remembering that all of these came out of [SD6](https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations) which says: "The value specified for a feature-test macro is based on the year and month in which the feature is voted into the working draft. In a case where a feature is subsequently changed in a significant way, but arguably remains the same feature, the value of the macro is changed to indicate the “revision level” of the specification of the feature. However, in most cases it is expected that the presence of a feature can be determined by the presence of any non-zero macro value; for example:"

> Oh, also note that this could potentially be a huge breaking change, since users may rely on them guarding for a version.

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.

https://github.com/llvm/llvm-project/pull/102044