This re-formats a few headers that had become out-of-sync with respect
to formatting since we ran clang-format on the whole codebase. There's
surprisingly few instances of it.
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.
Some places in the format library were identified to benefit from
basic_string's from_range constructor. At that time that constructor was
not implemented. It's implemented now so adjust the code to use this new
constructor.
Reviewed By: #libc, var-const
Differential Revision: https://reviews.llvm.org/D156022
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
Both the tuple formatter and range formatter parse a bracket. Instead of
implementing this twice do it in the generic parser. This is preparation
to improve the diagnostics in the format library.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D155264
I did a manual review after the post-review comments in D149543
Reviewed By: #libc, philnik, ldionne
Differential Revision: https://reviews.llvm.org/D154122
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 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 LWG issue is based on the discussion regarding
P2733R3 Fix handling of empty specifiers in std::format
This paper was disussed and changed a few times in LEWG during the
Issaquah meeting. The paper was not voted in, instead LEWG asked for
a DR against C++26.
This LWG issue contains the direction voted by LEWG. This issue has not
been voted in yet. However it fixes some of the defencies on the
container based formatting. Without this fix the range-default-formatter
for strings looks bad when used in containers.
The changes of this issue match the intended changes of P27333.
type fmt before after (if changed)
---------------------------------------------------------------
char {} a
char {:?} 'a'
array<char, 1> {} ['a']
array<char, 1> {::} [a]
array<char, 1> {::c} [a]
array<char, 1> {::?} ['a']
map<char, char> {} {a: a} -> {'a': 'a'}
map<char, char> {::} {'a': 'a'}
set<char> {} {'a'}
set<char> {::} {a}
set<char> {::c} {a}
set<char> {::?} {'a'}
tuple<char> {} ('a')
stack<char> {} ['a']
stack<char> {::} [a]
stack<char> {::c} [a]
stack<char> {::?} ['a']
array<array<char, 1>, 1> {} [[a]] -> {'a': 'a'}
array<array<char, 1>, 1> {::} [['a']]
array<array<char, 1>, 1> {:::} [[a]]
array<array<char, 1>, 1> {:::c} [[a]]
array<array<char, 1>, 1> {:::?} [['a']]
array<tuple<char>, 1> {} [(a)] -> [('a')]
tuple<tuple<char>> {} ((a)) -> (('a'))
tuple<array<char, 1>> {} ([a]) -> (['a'])
Note the optimization text as mentioned in the tuple formatter can't be
done. The call to parse may affect the formatter so its state needs to
be preserved.
Reviewed By: ldionne, #libc, EricWF
Differential Revision: https://reviews.llvm.org/D145847
std::format is currently experimental, so there is technically no
deployment target requirement for it (since the only symbols required
for it are in `libc++experimental.a`).
However, some parts of std::format depend indirectly on the floating
point std::to_chars implementation, which does have deployment target
requirements.
This patch removes all the availability format for std::format and
updates the XFAILs in the tests to properly explain why they fail
on old deployment targets, when they do. It also changes a couple
of tests to avoid depending on floating-point std::to_chars when
it isn't fundamental to the test.
Finally, some tests are marked as XFAIL but I added a comment saying
TODO FMT This test should not require std::to_chars(floating-point)
These tests do not fundamentally depend on floating-point std::to_chars,
however they end up failing because calling std::format even without a
floating-point argument to format will end up requiring floating-point
std::to_chars. I believe this is an implementation artifact that could
be avoided in all cases where we know the format string at compile-time.
In the tests, I added the TODO comment only to the places where we could
do better and actually avoid relying on floating-point std::to_chars
because we know the format string at compile-time.
Differential Revision: https://reviews.llvm.org/D134598
LWG3839 range_formatter's set_separator, set_brackets, and
underlying functions should be noexcept
Adds tests for:
template<ranges::input_range R, class charT>
struct range-default-formatter<range_format::sequence, R, charT>
These were missing, the format functions tests for the sequences
are already present.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144286
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
The contiguous range made incorrect assumptions for certain input
ranges.
Fixes llvm.org/PR60164
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D142302
