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
Makes sure headers having a xxx_result as return type export the proper
header. Without exporting these modularized headers are not self
contained.
This is related to D136045.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D136711
LWG-3539 was already implemented but not marked as done.
LWG-3567 is implemented in this commit.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D112368
This partly reverts D133535 and enables CTAD for more parts in format.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D135292
This concept is introduced in P2286, but was implemented in libc++
before. This implementation was used in the library internally. This
implementation lacked the resolution of LWG3636. The original formatter
had a non-const member function that wasn't trivial to make a const
member. The recent parser improvements made this member a const member
in preparation of LWG3636.
Note LWG3636 isn't voted in. Its status is Ready. P2286's concept has
been written as-if LWG3636 is accepted and refers to that LWG issue.
Updates some tests make format a const member function and removes a
tests that's mainly a duplicate of the formattable concept test.
Implements
- LWG3636 formatter<T>::format should be const-qualified
Implements parts of
- P2286R8 Formatting Ranges
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D134110
This adds support for the new code points in the Extended Grapheme
Cluster algorithm. The algorithm itself has remained unchanged.
The width estimation still follows the rules of the Standard.
@cor3ntin filed
LWG3780 format's width estimation is too approximate and not forward compatible
to improve the estimate.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D134106
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
This is a re-application of the original patch by Eric Fiselier in
fcd549a7d8 which had been reverted due to reasons lost at this point.
I also added the macro to a few more types. Reviving this patch was
prompted by the discussion on https://llvm.org/D133425.
Differential Revision: https://reviews.llvm.org/D133535
By default, Clang does not include headers that are skipped due to
the include guard optimization in the --trace-includes output, which
breaks the use case that we were trying to use it for.
However, Clang does support the -fshow-skipped-includes flag, which
does exactly what we need and will result in an accurate include
graph.
As a fly-by fix, make sure that our includes don't differ between
-fexceptions and -fno-exceptions.
Differential Revision: https://reviews.llvm.org/D134829
Formatting the alternate form for the general categories should keep the
trailing zeros. This was reported by @fsb4000 in D131336.
The default format uses general formatting but this should not keep the
trailing zeros so the default format is not passed to the formatter.
While testing I found an off by one error; finding the exponent character
`e` in 1e+03 will start at after the `1` so a size of `4` can contain an
exponent.
Reviewed By: fsb4000, ldionne, #libc
Differential Revision: https://reviews.llvm.org/D131417
Move the concept to the concepts header and uses a name in the style of
P2286.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D131176
Implements:
- LWG3721 Allow an arg-id with a value of zero for width in std-format-spec
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D130649
This version is build without support for the experimental library but
the code still wants to link this function. Inlining the function solves
the issue.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D132667
While working on D129964 I noticed some code hadn't been uglyfied, this
rectifies the issue.
Depends on D129964
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D131834
This improves the formatting of the generated files. That allows it to
remove the clang-format step in D129668.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D130911
This implements the Grapheme clustering as required by
P1868R2 width: clarifying units of width and precision in std::format
This was omitted in the initial patch, but the paper was marked as completed. This really completes the paper.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D126971
A format string like "{}" is quite common. In this case avoid parsing
the format-spec when it's not present. Before the parsing was always
called, therefore some refactoring is done to make sure the formatters
work properly when their parse member isn't called.
From the wording it's not entirely clear whether this optimization is
allowed
[tab:formatter]
```
and the range [pc.begin(), pc.end()) from the last call to f.parse(pc).
```
Implies there's always a call to `f.parse` even when the format-spec
isn't present. Therefore this optimization isn't done for handle
classes; it's unclear whether that would break user defined formatters.
The improvements give a small reduciton is code size:
719408 12472 488 732368 b2cd0 before
718824 12472 488 731784 b2a88 after
The performance benefits when not using a format-spec are:
```
Comparing ./formatter_int.libcxx.out-baseline to ./formatter_int.libcxx.out
Benchmark Time CPU Time Old Time New CPU Old CPU New
----------------------------------------------------------------------------------------------------------------------------------------------------
BM_Basic<uint32_t> -0.0688 -0.0687 67 62 67 62
BM_Basic<int32_t> -0.1105 -0.1107 73 65 73 65
BM_Basic<uint64_t> -0.1053 -0.1049 95 85 95 85
BM_Basic<int64_t> -0.0889 -0.0888 93 85 93 85
BM_BasicLow<__uint128_t> -0.0655 -0.0655 96 90 96 90
BM_BasicLow<__int128_t> -0.0693 -0.0694 97 90 97 90
BM_Basic<__uint128_t> -0.0359 -0.0359 256 247 256 247
BM_Basic<__int128_t> -0.0414 -0.0414 239 229 239 229
```
For the cases where a format-spec is used the results remain similar,
some are faster some are slower, differing per run.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D129426
This implements a not accepted LWG issue. Not doing so would require
integral types to use the handle class instead of being directly stored
in the basic_format_arg.
The previous code used `std::forward` in places where it wasn't required
by the Standard. These are now removed.
Implements:
- P2418R2 Add support for std::generator-like types to std::format
- LWG 3631 basic_format_arg(T&&) should use remove_cvref_t<T> throughout
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D127570
With to_chars supporting 128-bit it's possible to support the full
128-bit range in format. This only removes the previous restrictions
and updates the tests to validate proper support.
Depends on D128929.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D129007
This removes a part of the now obsolete formater code.
The removal also removes the _v2 suffix where it's no longer needed.
Depends on D128785
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128846
This changes the implementation of the formatter. Instead of inheriting
from a specialized parser all formatters will use the same generic
parser. This reduces the binary size.
The new parser contains some additional fields only used in the chrono
formatting. Since this doesn't change the size of the parser the fields
are in the generic parser. The parser is designed to fit in 128-bit,
making it cheap to pass by value.
The new format function is a const member function. This isn't required
by the Standard yet, but it will be after LWG-3636 is accepted.
Additionally P2286 adds a formattable concept which requires the member
function to be const qualified in C++23. This paper is likely to be
accepted in the 2022 July plenary.
This is based on D125606. That commit did the groundwork and did similar
changes for the string formatters.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128785
This changes the implementation of the formatter. Instead of inheriting
from a specialized parser all formatters will use the same generic
parser. This reduces the binary size.
The new parser contains some additional fields only used in the chrono
formatting. Since this doesn't change the size of the parser the fields
are in the generic parser. The parser is designed to fit in 128-bit,
making it cheap to pass by value.
The new format function is a const member function. This isn't required
by the Standard yet, but it will be after LWG-3636 is accepted.
Additionally P2286 adds a formattable concept which requires the member
function to be const qualified in C++23. This paper is likely to be
accepted in the 2022 July plenary.
This is based on D125606. That commit did the groundwork and did similar
changes for the string formatters.
Depends on D128139.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128671
This changes the implementation of the formatter. Instead of inheriting
from a specialized parser all formatters will use the same generic
parser. This reduces the binary size.
The new parser contains some additional fields only used in the chrono
formatting. Since this doesn't change the size of the parser the fields
are in the generic parser. The parser is designed to fit in 128-bit,
making it cheap to pass by value.
The new format function is a const member function. This isn't required
by the Standard yet, but it will be after LWG-3636 is accepted.
Additionally P2286 adds a formattable concept which requires the member
function to be const qualified in C++23. This paper is likely to be
accepted in the 2022 July plenary.
This is based on D125606. That commit did the groundwork and did similar
changes for the string formatters.
Depends on D125606
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128139
This is a helper patch to ease the reviewing of D128139.
The originals will be removed at a later time when all formatters are
converted to the new style. (Floating-point and pointer aren't up for
review yet.)
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128367
This changes the implementation of the formatter. Instead of inheriting
from a specialized parser all formatters will use the same generic
parser. This reduces the binary size.
The new parser contains some additional fields only used in the chrono
formatting. Since this doesn't change the size of the parser the fields
are in the generic parser. The parser is designed to fit in 128-bit,
making it cheap to pass by value.
The new format function is a const member function. This isn't required
by the Standard yet, but it will be after LWG-3636 is accepted.
Additionally P2286 adds a formattable concept which requires the member
function to be const qualified in C++23. This paper is likely to be
accepted in the 2022 July plenary.
Depends on D121530
NOTE parts of the code now contains duplicates for the current and new parser.
The intention is to remove the duplication in followup patches. A general
overview of the final code is available in D124620. That review however lacks a
bit of polish.
Most of the new code is based on the same algorithms used in the current code.
The final version of this code reduces the binary size by 17 KB for this example
code
```
int main() {
{
std::string_view sv{"hello world"};
std::format("{}{}|{}{}{}{}{}{}|{}{}{}{}{}{}|{}{}{}|{}{}|{}", true, '*',
(signed char)(42), (short)(42), (int)(42), (long)(42), (long long)(42), (__int128_t)(42),
(unsigned char)(42), (unsigned short)(42), (unsigned int)(42), (unsigned long)(42),
(unsigned long long)(42), (__uint128_t)(42),
(float)(42), (double)(42), (long double)(42),
"hello world", sv,
nullptr);
}
{
std::wstring_view sv{L"hello world"};
std::format(L"{}{}|{}{}{}{}{}{}|{}{}{}{}{}{}|{}{}{}|{}{}|{}", true, L'*',
(signed char)(42), (short)(42), (int)(42), (long)(42), (long long)(42), (__int128_t)(42),
(unsigned char)(42), (unsigned short)(42), (unsigned int)(42), (unsigned long)(42),
(unsigned long long)(42), (__uint128_t)(42),
(float)(42), (double)(42), (long double)(42),
L"hello world", sv,
nullptr);
}
}
```
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D125606
Louis Dionne