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.)