Also introduce `_LIBCPP_ASSERT_PEDANTIC` for assertions violating which
results in a no-op or other benign behavior, but which may nevertheless
indicate a bug in the invoking code.
Improves both the compile-time and run-time errors.
At compile-time it does a bit more work to get more specific errors.
This could be done at run-time too, but that has a performance penalty.
Since it's expected most use-cases use format* instead of vformat* the
compile-time errors are more common.
For example when using
std::format_to("{:-c}", 42);
Before compile output would contain
std::__throw_format_error("The format-spec should consume the input or end with a '}'");
Now it contains
std::__throw_format_error("The format specifier does not allow the sign option");
Given a better indication the sign option is not allowed. Note the
output is still not user-friendly; C++ doesn't have good facilities to
generate nice messages from the library.
In general all messages have been reviewed and improved, using a more
consistent style and using less terms used in the standard. For example
format-spec -> format specifier
arg-id -> argument index
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D152624
Replace most uses of `_LIBCPP_ASSERT` with
`_LIBCPP_ASSERT_UNCATEGORIZED`.
This is done as a prerequisite to introducing hardened mode to libc++.
The idea is to make enabling assertions an opt-in with (somewhat)
fine-grained controls over which categories of assertions are enabled.
The vast majority of assertions are currently uncategorized; the new
macro will allow turning on `_LIBCPP_ASSERT` (the underlying mechanism
for all kinds of assertions) without enabling all the uncategorized
assertions (in the future; this patch preserves the current behavior).
Differential Revision: https://reviews.llvm.org/D153816
The code has been quite ready for a while now and there are no more ABI
breaking papers. So this is a good time to mark the feature as stable.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D150802
The newer formatters for (tuple, vector<bool>::reference) specify the
formatter's parse and format member function. This signature is slightly
different from the signature for existing formatters. Adapt the existing
formatters to the new style.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D150034
This change is almost fully mechanical. The only interesting change is in `generate_feature_test_macro_components.py` to generate `_LIBCPP_STD_VER >=` instead. To avoid churn in the git-blame this commit should be added to the `.git-blame-ignore-revs` once committed.
Reviewed By: ldionne, var-const, #libc
Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei
Differential Revision: https://reviews.llvm.org/D143962
Partially implements:
- P1361 Integration of chrono with text formatting
- P2372 Fixing locale handling in chrono formatters
- P1466 Miscellaneous minor fixes for chrono
Depends on D137022
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D139771
Some of the calendar types have landed before, this adds the missing
set. Note this does not complete the implementation of the chrono
formatters.
This removes the `chrono` header for some transitive include in C++17
mode. This is needed to avoid inclusion cycles.
Partially implements:
- P1361 Integration of chrono with text formatting
- P2372 Fixing locale handling in chrono formatters
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D137022
Partially implements:
- P1361 Integration of chrono with text formatting
- P2372 Fixing locale handling in chrono formatters
- LWG3270 Parsing and formatting %j with durations
Completes:
- P1650R0 std::chrono::days with 'd' suffix
- LWG3262 Formatting of negative durations is not specified
- LWG3314 Is stream insertion behavior locale dependent when Period::type is micro?
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D134742
