The post-condition on the functions is that the buffer is not full.
This post-conditon is used as pre-condition of the push_back function.
When a copy, fill, of transform function exactly fit in the buffer this
post-condition was validated.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D155397
<__format/format_functions.h> was using <string>, we need to bring the include back that was removed in D154122.
Reviewed By: Mordante, #libc
Differential Revision: https://reviews.llvm.org/D155116
This should reduce the size of the transitive includes for the vector header.
Note the header still quite large so the difference may be small.
Depends on D154122
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D154286
I did a manual review after the post-review comments in D149543
Reviewed By: #libc, philnik, ldionne
Differential Revision: https://reviews.llvm.org/D154122
The feature is applied as DR instead of a normal paper. MSVC STL and
libstdc++ will do the same.
Implements
- P2510R3 Formatting pointers
Depends on D153192
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D153195
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
`__iterator/readable_traits.h` can't be used by itself, intantiating `iter_value_t` requires `__iterator/iterator_traits.h`. `readable_traits.h` can't include `iterator_traits.h` though because `iterator_traits.h` requires `readable_traits.h`.
Move `iter_value_t` to `__iterator/iterator_traits.h` so that both headers can work standalone.
Reviewed By: Mordante, #libc
Differential Revision: https://reviews.llvm.org/D153828
This change has a few additional effects:
- Abstract classes are now formattable.
- Volatile objects are no longer formattable.
Implements
- LWG3631 basic_format_arg(T&&) should use remove_cvref_t<T> throughout
- LWG3925 Concept formattable's definition is incorrect
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D152092
This work-around was for Clang 13 and older, which we no longer support.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D152175
The mask used to check whether a code unit is a valid continuation was
incorrect and accepts non-continuation code points. This fixes the
issue.
Reviewed By: ldionne, tahonermann, #libc
Differential Revision: https://reviews.llvm.org/D149672
These macros are always defined identically, so we can simplify the code a bit by merging them.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, krytarowski, smeenai
Differential Revision: https://reviews.llvm.org/D152652
This is an extension and only adds the functions that are a considered a
but when called and ignoring the result.
Drive-by sort all nodiscard extensions in the documentation.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D152097
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 main change is to allow a UCS scalar value as fill character.
Especially for char based formatting this increase the number of valid
characters. Originally this was to be expected ABI breaking, however the
current change does not seem to break the ABI.
Implements
- P2572 std::format() fill character allowances
Depends on D144499
Reviewed By: ldionne, tahonermann, #libc
Differential Revision: https://reviews.llvm.org/D144742
The source file is used to anchor the destructor of format_error. When
format is moved from experimental to stable this code would move to the
dylib. One issue with code in the dylib is that it can't be used in
constexpr context. There is a proposal to make format work during
constant evaluation
P2758 Emitting messages at compile time
This paper has initially been received favourable by EWG. Therefore move
the code to the header. This also avoids possible availability issues on
Mac back deployment targets.
Note it is expected that format will no longer be experimental with the
next LLVM release.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D150073
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
Several headers are missing includes for things they use.
type_traits.is_enum needs to export type_traits.integral_constant so that clients can access its `value` member without explicitly including __type_traits/integral_constant.h themselves.
Make `subrange_fwd` a peer submodule to `subrange` rather than a submodule of it, and have `subrange` export `subrange_fwd`. That will make it easier to programmatically generate modules for the private detail headers, and it will accomplish the same effect that __ranges/subrange.h will make subrange_kind visible.
Reviewed By: Mordante, #libc
Differential Revision: https://reviews.llvm.org/D150055
During the review of D140653 it was suggested to use vector in
__retarget_buffer instead of manually managing the memory. Due to the
requirements of the Standard it turns out format needs to include vector
leading to a cycle. Therefore switching back to manual memory
management.
This is a preparation to fix https://llvm.org/PR61314
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D148826
As obvious from the paper's title this is an LWG issue and thus retroactively
applied to C++20. This change may the output for certain code points:
1 Considers 8477 extra codepoints as having a width 2 (as of Unicode 15)
(mostly Tangut Ideographs)
2 Change the width of 85 unassigned code points from 2 to 1
3 Change the width of 8 codepoints (in the range U+3248 CIRCLED NUMBER
TEN ON BLACK SQUARE ... U+324F CIRCLED NUMBER EIGHTY ON BLACK
SQUARE) from 2 to 1, because it seems questionable to make an exception
for those without input from Unicode
Note that libc++ already uses Unicode 15, while the Standard requires Unicode 12.
(The last time I checked MSVC STL used Unicode 14.)
So in practice the only notable change is item 3.
Implements
P2675 LWG3780: The Paper
format's width estimation is too approximate and not forward compatible
Benchmark before these changes
--------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------
BM_ascii_text<char> 3928 ns 3928 ns 178131
BM_unicode_text<char> 75231 ns 75230 ns 9158
BM_cyrillic_text<char> 59837 ns 59834 ns 11529
BM_japanese_text<char> 39842 ns 39832 ns 17501
BM_emoji_text<char> 3931 ns 3930 ns 177750
BM_ascii_text<wchar_t> 4024 ns 4024 ns 174190
BM_unicode_text<wchar_t> 63756 ns 63751 ns 11136
BM_cyrillic_text<wchar_t> 44639 ns 44638 ns 15597
BM_japanese_text<wchar_t> 34425 ns 34424 ns 20283
BM_emoji_text<wchar_t> 3937 ns 3937 ns 177684
Benchmark after these changes
--------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------
BM_ascii_text<char> 3914 ns 3913 ns 178814
BM_unicode_text<char> 70380 ns 70378 ns 9694
BM_cyrillic_text<char> 51889 ns 51877 ns 13488
BM_japanese_text<char> 41707 ns 41705 ns 16723
BM_emoji_text<char> 3908 ns 3907 ns 177912
BM_ascii_text<wchar_t> 3949 ns 3948 ns 177525
BM_unicode_text<wchar_t> 64591 ns 64587 ns 10649
BM_cyrillic_text<wchar_t> 44089 ns 44078 ns 15721
BM_japanese_text<wchar_t> 39369 ns 39367 ns 17779
BM_emoji_text<wchar_t> 3936 ns 3934 ns 177821
Benchmarks without "if(__code_point < (__entries[0] >> 14))"
--------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------
BM_ascii_text<char> 3922 ns 3922 ns 178587
BM_unicode_text<char> 94474 ns 94474 ns 7351
BM_cyrillic_text<char> 69202 ns 69200 ns 10157
BM_japanese_text<char> 42735 ns 42692 ns 16382
BM_emoji_text<char> 3920 ns 3919 ns 178704
BM_ascii_text<wchar_t> 3951 ns 3950 ns 177224
BM_unicode_text<wchar_t> 81003 ns 80988 ns 8668
BM_cyrillic_text<wchar_t> 57020 ns 57018 ns 12048
BM_japanese_text<wchar_t> 39695 ns 39687 ns 17582
BM_emoji_text<wchar_t> 3977 ns 3976 ns 176479
This optimization does carry its weight for the Unicode and Cyrillic
test. For the Japanese tests the gains are minor and for emoji it seems
to have no effect.
Reviewed By: ldionne, tahonermann, #libc
Differential Revision: https://reviews.llvm.org/D144499
This patch makes are code less dependant on transitive includes.
This was part of D145800. This patch will be abandoned, but these
changes are still useful. I manually verified declarations of the new
includes are used in these files.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D148645
We already have a clang-tidy check for making sure that `_LIBCPP_HIDE_FROM_ABI` is on free functions. This patch extends this to class members. The places where we don't check for `_LIBCPP_HIDE_FROM_ABI` are classes for which we have an instantiation in the library.
Reviewed By: ldionne, Mordante, #libc
Spies: jplehr, mikhail.ramalho, sstefan1, libcxx-commits, krytarowski, miyuki, smeenai
Differential Revision: https://reviews.llvm.org/D142332
This file was added before we started granularizing the headers, but is essentially just a granularized header. This moves the header to the correct place.
Reviewed By: #libc, EricWF
Spies: libcxx-commits, arichardson, mikhail.ramalho
Differential Revision: https://reviews.llvm.org/D146395
LWG3720 Restrict the valid types of arg-id for width and precision in
std-format-spec
Depends on D144325
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144326
Since stacktrace header is WIP and it's not sure that will be done
before LLVM17 update the documentation. When the header is implemented
implementing the formatter is trivial, so that can be done quickly
afterwards.
Implements parts of:
- P2693R1 Formatting thread::id and stacktrace
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144331
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
Having the header granularized makes it possible to remove the
dependency on this header in <format>. This <format> header gets
included in more headers due to more usage of std::formatter in the
library. This should reduce the number of transitive includes.
Note formatting the new headers will be done in a followup patch.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D145590
While implementing the tests for LWG3720 I noticed the std::format
errors for non-formattable types are not user friendly (and thus hard to
write a .verify test too).
The issue stems from using a deleted function for invalid types. By
using a function that returns an invalid value the diagnostics become a
lot better. Before this change the existing "invalid value"
static_assert could never trigger. Now it can be triggered by user
code, therefore a diagnostic message has been added.
Before this change using a non-formattable type resulted in list of
error messages along the line of
.../include/c++/v1/__format/format_arg_store.h:167:29: error: call to deleted function '__determine_arg_t'
constexpr __arg_t __arg = __determine_arg_t<_Context, remove_cvref_t<_Tp>>();
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../include/c++/v1/__format/format_arg_store.h:210:54: note: in instantiation of function template specialization 'std::__format::__create_format_arg<std::format_context, char16_t &>' requested here
basic_format_arg<_Context> __arg = __format::__create_format_arg<_Context>(__args);
^
.../include/c++/v1/__format/format_arg_store.h:246:19: note: in instantiation of function template specialization 'std::__format::__create_packed_storage<std::format_context, int &, char16_t &>' requested here
__format::__create_packed_storage(__storage.__types_, __storage.__values_, __args...);
^
.../include/c++/v1/__format/format_functions.h:73:10: note: in instantiation of member function 'std::__format_arg_store<std::format_context, int &, char16_t &>::__format_arg_store' requested here
return _VSTD::__format_arg_store<_Context, _Args...>(__args...);
^
.../include/c++/v1/__config:664:17: note: expanded from macro '_VSTD'
# define _VSTD std
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:46:50: note: in instantiation of function template specialization 'std::make_format_args<std::format_context, int &, char16_t &>' requested here
TEST_IGNORE_NODISCARD std::vformat(fmt, std::make_format_args<context_t<CharT>>(args...));
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:69:3: note: in instantiation of function template specialization 'test_exception<char, int, char16_t>' requested here
test_exception(SV("{:{}}"), 42, u'0');
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:97:3: note: in instantiation of function template specialization 'test<char>' requested here
test<char>();
^
.../include/c++/v1/__format/format_arg_store.h:154:19: note: candidate function [with _Context = std::format_context, _Tp = char16_t] has been explicitly deleted
consteval __arg_t __determine_arg_t()
^
.../include/c++/v1/__format/format_arg_store.h:148:19: note: candidate function [with _Context = std::format_context, _Tp = char16_t]
consteval __arg_t __determine_arg_t() {
<more errors omitted>
.../include/c++/v1/__format/format_arg_store.h:185:22: note: initializer of '__arg' is not a constant expression
.../include/c++/v1/__format/format_arg_store.h:167:21: note: declared here
constexpr __arg_t __arg = __determine_arg_t<_Context, remove_cvref_t<_Tp>>();
^
.../build/include/c++/v1/__format/format_arg_store.h:194:73: error: member reference base type 'char16_t' is not a structure or union
__arg, basic_string_view<typename _Context::char_type>{__value.data(), __value.size()}};
~~~~~~~^~~~~
11 errors generated.
After the change using the same non-formmatable type gives the following
diagnostics
.../include/c++/v1/__format/format_arg_store.h:168:3: error: static assertion failed due to requirement '__arg != __arg_t::__none': the supplied type is not formattable
static_assert(__arg != __arg_t::__none, "the supplied type is not formattable");
^ ~~~~~~~~~~~~~~~~~~~~~~~~
.../include/c++/v1/__format/format_arg_store.h:210:54: note: in instantiation of function template specialization 'std::__format::__create_format_arg<std::format_context, char16_t &>' requested here
basic_format_arg<_Context> __arg = __format::__create_format_arg<_Context>(__args);
^
.../include/c++/v1/__format/format_arg_store.h:246:19: note: in instantiation of function template specialization 'std::__format::__create_packed_storage<std::format_context, int &, char16_t &>' requested here
__format::__create_packed_storage(__storage.__types_, __storage.__values_, __args...);
^
.../include/c++/v1/__format/format_functions.h:73:10: note: in instantiation of member function 'std::__format_arg_store<std::format_context, int &, char16_t &>::__format_arg_store' requested here
return _VSTD::__format_arg_store<_Context, _Args...>(__args...);
^
.../include/c++/v1/__config:664:17: note: expanded from macro '_VSTD'
# define _VSTD std
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:46:50: note: in instantiation of function template specialization 'std::make_format_args<std::format_context, int &, char16_t &>' requested here
TEST_IGNORE_NODISCARD std::vformat(fmt, std::make_format_args<context_t<CharT>>(args...));
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:69:3: note: in instantiation of function template specialization 'test_exception<char, int, char16_t>' requested here
test_exception(SV("{:{}}"), 42, u'0');
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:97:3: note: in instantiation of function template specialization 'test<char>' requested here
test<char>();
^
.../include/c++/v1/__format/format_arg_store.h:168:23: note: expression evaluates to '0 != 0'
static_assert(__arg != __arg_t::__none, "the supplied type is not formattable");
~~~~~~^~~~~~~~~~~~~~~~~~
1 error generated.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144325
This patch also updates the moved code to the new style (i.e. formatted, replaced marcos and typedefs)
Reviewed By: ldionne, #libc
Spies: arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D145095
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
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
