We don't support any compiler that doesn't support C++14 constexpr when
compiling in C++14 mode anymore, so we can just assume that we have C++14
extended constexpr when compiling in C++14 mode. This allows us to remove
some workarounds for older compilers.
Details
- Reviewers
• Quuxplusone ldionne - Group Reviewers
Restricted Project - Commits
- rG77b32055ec8d: [libc++] Assume that compilers support extended constexpr in C++14 mode
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM % if there's anything to do about my comment.
libcxx/include/__config | ||
---|---|---|
565–567 | Should this number be bumped upward? Or does _MSC_VER==1900 actually support C++14 constexpr, and we just didn't notice it until now? IIUC, this is a "major NFC" change ;) — we used to never use C++14 constexpr on _LIBCPP_COMPILER_MSVC, and now we're going to always use it. Right? (Not a "problem" per se, but noteworthy.) |
libcxx/include/__config | ||
---|---|---|
565–567 | I remember seeing a mention somewhere, that the biggest blocker is that MSVC doesn't support #include_next, which pretty much blocks it from even trying to use our headers. In this case, the MSVC version number here corresponds to the version of MSVC that clang-cl impersonates, and also implying what version of the MSVC runtime is being used. |
Should this number be bumped upward? Or does _MSC_VER==1900 actually support C++14 constexpr, and we just didn't notice it until now?
IIUC, this is a "major NFC" change ;) — we used to never use C++14 constexpr on _LIBCPP_COMPILER_MSVC, and now we're going to always use it. Right? (Not a "problem" per se, but noteworthy.)