This is the first step at implementing <format>. It adds the <format> header
and implements the format_error. class.
Implemnts parts of:
-P0645 Text Formatting
Differential D92214
[libc++] Implement format_error. Mordante on Nov 27 2020, 1:10 AM. Authored by
Details
This is the first step at implementing <format>. It adds the <format> header Implemnts parts of:
Diff Detail
Unit Tests Event Timeline
Comment Actions Thanks for the review! It seems a build bot fails. I'll investigate this further.
Comment Actions Properly guard the code in format.cpp to only be used in C++20 mode. Comment Actions To fix Apple back-deployment build, you'll need to mark your test with sth like: // This test requires the dylib support introduced in D92214. // XFAIL: with_system_cxx_lib=macosx10.15 // XFAIL: with_system_cxx_lib=macosx10.14 // XFAIL: with_system_cxx_lib=macosx10.13 // XFAIL: with_system_cxx_lib=macosx10.12 // XFAIL: with_system_cxx_lib=macosx10.11 // XFAIL: with_system_cxx_lib=macosx10.10 // XFAIL: with_system_cxx_lib=macosx10.9 because this build uses a released dylibs for the given version of macOS (here 10.9) and does not use whatever changes you put in src/. Comment Actions Looks okay except for the synopsis nitpick, however as you say the Apple ABI list needs to be updated. If you rebase on top of master and re-submit, the failing jobs should tell you what symbols you're missing (in the logs). You could add them to the Apple ABI lists (please make sure to sort :-), and the CI should pass.
Comment Actions
Comment Actions Thanks! The CI has been a bit grumpy the last days, but hopefully it should be back to normal now. Comment Actions Hello, this again breaks building with -std=c++17: the cpp file has the definition but not the declaration in that case. Should libc++ sources be built with -std=c++20? Or should the cpp file also check _LIBCPP_STD_VER? Comment Actions ... but it looks like CXX_STANDARD_REQUIRED should now become YES after this change here, right? Comment Actions I had this in my original version, but I removed it after review this review comment
That doesn't really answer the question since that made C++20 preferred but not mandatory. That was the intention. @ldionne Can you clarify the status of libc++'s C++20 requirements. If optional should I re-add the version check macro's in the .cpp file? Comment Actions Ugh. That's tough. First, we can't always build as C++17 because then the dylib can't provide the features it needs to support c++20 (unless we jump through some hoops to compile with C++17 but enable stuff like char8_t, which is a no-no). Comment Actions Indeed, not using C++20 to compile the library would prevent us from implementing any C++20 features, char8_t support is one example, format_error is another. Just my 2 cents. Anyway, guarding C++20 features in src/ so as to allow the build and use in C++17 would probably be the way to go for the moment. Comment Actions I agree it would be nice to allow C++17 and C++20 for a limited time. It would be a bit of a maintenance burden, but I feel it benefits our users. I think we can state users are allowed to use C++17, but it's not officially supported. We could make a Cmake switch to opt-in to this behavior, but I feel that would be overkill. I think once C++20 becomes mandatory we should remove the #if _LIBCPP_STD_VER > 17 from the files in src. Then the extra burden is only there for a limited time. I'll make a patch to remove the 2 occurrences of #if _LIBCPP_STD_VER > 11 from src. Comment Actions
Yes, I agree.
No, that's actually what we do all the time. We build the dylib in C++20, but users are free to use the headers in C++03, C++11, C++14, C++17 or C++20 mode. @Mordante Feel free to add back the check. However, in the short/mid term, I want the default way to build libc++ to switch to the bootstrap build (i.e. the Runtimes build). Once that happens, we will be guaranteed that we always build the dylib with basically Clang trunk (or a recent compiler anyway). It won't make sense anymore to allow anything but the latest standard then. It is indeed a maintenance burden to support more than that, and a burden that (I claim) doesn't provide much benefit. If you're compiling the C++ Standard Library from scratch, I think you have the time and dedication to keep your compiler up to date. Comment Actions I'll commit a fix.
Sounds good to me. |
The synopsis should only contain the parts that we implement. Or at least it's always been my impression.