================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
