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
Instead of writing something like `XFAIL: use_system_cxx_lib && target=...`
to XFAIL back-deployment tests, introduce named Lit features like
`availability-shared_mutex-missing` to represent those. This makes the
XFAIL annotations leaner, and solves the problem of XFAIL comments
potentially getting out of sync. This would also make it easier for
another vendor to add their own annotations to the test suite by simply
changing how the feature is defined for their OS releases, instead
of having to modify hundreds of tests to add repetitive annotations.
This doesn't touch *all* annotations -- only annotations that were widely
duplicated are given named features (e.g. when filesystem or shared_mutex
were introduced). I still think it probably doesn't make sense to have a
named feature for every single fix we make to the dylib.
This is in essence a revert of 2659663, but since then the test suite
has changed significantly. Back when I did 2659663, the configuration
files we have for the test suite right now were being bootstrapped and
it wasn't clear how to provide these features for back-deployment in
that context. Since then, we have a streamlined way of defining these
features in `features.py` and that doesn't impact the ability for a
configuration file to stay minimal.
The original motivation for this change was that I am about to propose
a change that would touch essentially all XFAIL annotations for back-deployment
in the test suite, and this greatly reduces the number of lines changed
by that upcoming change, in addition to making the test suite generally
better.
Differential Revision: https://reviews.llvm.org/D146359
Those seem to have been failing for a while but we might not have noticed
because of the recent CI instability issues. I'm marking them as unsupported
to try to get the CI functional again, especially since the majority of
<format> tests are already not working on GCC 12.
This has been done using the following command
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)(?<!::u)u?intptr_t)|\1std::\2|' \{} \;
The std module doesn't export declarations in the global namespaace.
This is a preparation for that module.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D146643
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
This has been done using the following commands
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)ptrdiff_t)|\1std::\2|' \{} \;
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)max_align_t)|\1std::\2|' \{} \;
The std module doesn't export declarations in the global namespaace.,
This is a preparation for that module.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D146550
This has been done using the following command
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)size_t)|\1std::\2|' \{} \;
And manually removed some false positives in std/depr/depr.c.headers.
The `std` module doesn't export `::size_t`, this is a preparation for that module.
Reviewed By: ldionne, #libc, EricWF, philnik
Differential Revision: https://reviews.llvm.org/D146088
We pretty consistently don't define those cause they are not needed,
and it removes the potential pitfall to think that these tests are
being run. This doesn't touch .compile.fail.cpp tests since those
should be replaced by .verify.cpp tests anyway, and there would be
a lot to fix up.
As a fly-by, I also fixed a bit of formatting, removed a few unused
includes and made some very minor, clearly NFC refactorings such as
in allocator.traits/allocator.traits.members/allocate.verify.cpp where
the old test basically made no sense the way it was written.
Differential Revision: https://reviews.llvm.org/D146236
This has been done using the following command
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)(?<!::u)u?int(_[a-z]+)?[0-9]{1,2}_t)|\1std::\2|' \{} \;
And manually removed some false positives in std/depr/depr.c.headers.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D145880
During the implementation of P2286 a second Unicode decoder was added.
The original decoder was only used for the width estimation. Changing
an ill-formed Unicode sequence to the replacement character, works
properly for this use case. For P2286 an ill-formed Unicode sequence
needs to be formatted as a sequence of code units. The exact wording in
the Standard as a bit unclear and there was odd example in the WP. This
made it hard to use the same decoder. SG16 determined the odd example in
the WP was a bug and this has been fixed in the WP.
This made it possible to combine the two decoders. The P2286 decoder
kept track of the size of the ill-formed sequence. However this was not
needed since the output algorithm needs to keep track of size of a
well-formed and an ill-formed sequence. So this feature has been
removed.
The error status remains since it's needed for P2286, the grapheme
clustering can ignore this unneeded value. (In general, grapheme
clustering is only has specified behaviour for Unicode. When the string
is in a non-Unicode encoding there are no requirements. Ill-formed
Unicode is a non-Unicode encoding. Still libc++ does a best effort
estimation.)
There UTF-8 decoder accepted several ill-formed sequences:
- Values in the surrogate range U+D800..U+DFFF.
- Values encoded in more code units than required, for example 0+0020
in theory can be encoded using 1, 2, 3, or 4 were accepted. This is
not allowed by the Unicode Standard.
- Values larger than U+10FFFF were not always rejected.
Reviewed By: #libc, ldionne, tahonermann, Mordante
Differential Revision: https://reviews.llvm.org/D144346
The module std does not provide c-types in the global namespace. This
means all these types need to be fully qualified. This is a first step
to convert them by using sed.
Since this is an automated conversion other types like uint64_t are kept
as is.
Note that tests in the directory libcxx/test/std/depr/depr.c.headers
should not be converted automatically. This requires manual attention,
there some test require testing uint32_t in the global namespace. These
test should fail when using the std module, and pass when using the
std.compat module.
A similar issue occurs with atomic, atomic_uint32_t is specified as
using atomic_uint32_t = atomic<uint32_t>; // freestanding
So here too we need to keep the name in the global namespace in the
tests.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D145520
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
The m type in a range formatter may only be used when a pair or a tuple
with two elements is used. This was not correctly validated as reported
in llvm.org/PR60995.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D145309
Fixes llvm.org/PR58714 reported by @jwakely and a similar issue
reported privately by @vitaut.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D145306
Formatting a const qualified vector<bool> fails to work on libc++. This
is due to our non-conforming type for vector<bool>::const_reference. The
type is a __bit_const_reference<vector> instead of a bool. (This is
fixed in ABI v2.)
This fixes this formatter and enables the test written for it.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144279
These macros are intended to replace the macros in rapid-cxx-test.h.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D142808
Using some builds the modular build fails due to missing exports
and includes. This fixes the build.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D143203
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
The constexpr validation parsed parts of the format string that didn't
belong to the specific replacement field.
Fixes https://llvm.org/PR60536
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D143402
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
These macros make it easier to log additional information. This is
useful for formatting tests. It also properly disables additional
information when locales are disabled in libc++.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D140651
This reverts commit a6e1080b87db8fbe0e1afadd96af5a3c0bd5e279.
Fix the conditions when the `memmove` optimization can be applied and refactor them out into a reusable type trait, fix and significantly expand the tests.
Differential Revision: https://reviews.llvm.org/D139235
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
The format function test serve two purposes:
- Test whether all format functions work in general.
- Test whether all formatting rules are implemented correctly.
At the moment the *pass.cpp tests do both. These tests are quite slow,
while testing all rules for all functions doesn't add much coverage.
There are two execution modi of the format functions:
- run-time validation in the vformat functions.
- compile-time validation in the other function.
So instead of running all tests for all functions, they are only used for
format.pass.cpp and vformat.pass.cpp still do all tests.
The other tests do a smaller set of test, just to make sure they work in the
basics.
Running the format tests using one thread:
- before 00:04:16
- after 00:02:14
The slow tests were also reported in
https::llvm.org/PR58141
Also split a generic part of the test to a generic support header. This
allows these parts to be reused in the range-based formatter tests.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D140115
This adds an incomplete version where the specializations for the
format_kinds are disabled dummy formatters.
Implements part of
- P2585R0 Improving default container formatting
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D137271
Per our policy, the latest released AppleClang has been 14 for a while,
so libc++ is removing support for AppleClang 13. Our CI bots have been
moved to AppleClang 14 a few weeks ago.
Differential Revision: https://reviews.llvm.org/D138685
The Standard specifies which types are stored in the basic_format_arg
"variant" and which types are stored as a handle. Libc++ stores
additional types in the "variant". During a reflector discussion
@jwakely mention this is user observable; visit_format_arg uses the type
instead of a handle as argument.
This optimization is useful and will probably be used for other small
types in the future. To be conferment the visitor creates a handle and
uses that as argument. There is a second visitor so the formatter can
still directly access the 128-bit integrals.
The test for the visitor and get has been made public too, there is no
reason not too. The 128-bit integral types are required by the Standard,
when they are available.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D138052
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
