33 Commits

Author SHA1 Message Date
Louis Dionne
348e74139a [libc++][NFC] Run clang-format on libcxx/include
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.
2024-08-30 12:09:36 -04:00
Nikolas Klauser
ffb3589b8c
[libc++] Remove transitive <locale> include from <vector> (#80282)
This reduces the time to include `<vector>` from 468ms to 367ms.
2024-02-02 11:33:08 +01:00
Konstantin Varlamov
4f215fdd62
[libc++][hardening] Categorize more assertions. (#75918)
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.
2024-01-05 16:29:23 -08:00
Louis Dionne
9783f28cbb
[libc++] Format the code base (#74334)
This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmarks, the test suite and remaining parts of the code. I'm
splitting this one into its own patch so the diff is a bit easier to
review.

This patch was generated with:

   find libcxx/include libcxx/src -type f \
      | grep -v 'module.modulemap.in' \
      | grep -v 'CMakeLists.txt' \
      | grep -v 'README.txt' \
      | grep -v 'libcxx.imp' \
      | grep -v '__config_site.in' \
      | xargs clang-format -i

A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh
to help resolve merge and rebase issues across these formatting changes.

[1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
2023-12-18 14:01:33 -05:00
Louis Dionne
a35629cd8d
[libc++] Remove assumptions that std::array::iterator is a raw pointer (#74624)
This patch removes assumptions that std::array's iterators are raw
pointers in the source code and in our test suite. While this is true
right now, this doesn't have to be true and ion the future we might want
to enable bounded iterators in std::array, which would require this
change.

This is a pre-requisite for landing #74482
2023-12-18 10:00:47 -05:00
Louis Dionne
77a00c0d54
[libc++] Replace uses of _VSTD:: by std:: (#74331)
As part of the upcoming clang-formatting of libc++, this patch performs
the long desired removal of the _VSTD macro.

See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.
2023-12-05 11:19:15 -05:00
Mark de Wever
3ab20c6809 [libc++][format] Granularize formatter_output.
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
2023-07-10 19:30:26 +02:00
varconst
cd0ad4216c [libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED.
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
2023-06-28 15:10:31 -07:00
Mark de Wever
5db033e204 [libc++][format] Improves fill character.
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
2023-05-19 17:20:50 +02:00
Mark de Wever
b51e8acd82 [NFC][libc++][format] Uses uniform member signatures.
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
2023-05-12 17:48:23 +02:00
Nikolas Klauser
eb65912e41 [libc++] Move __errc to __system_error/errc.h
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
2023-04-10 19:23:42 +02:00
Mark de Wever
57e20cab5a [libc++][format] Use granularized charconv.
This reduces the number of transitive includes when using format.

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D146240
2023-04-07 17:49:21 +02:00
Mark de Wever
f7efcaca77 [libc++][charconv] Granularizes the header.
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
2023-03-15 18:01:53 +01:00
Nikolas Klauser
43562287a8 [libc++] Granularize <exception>
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
2023-03-12 22:19:41 +01:00
Nikolas Klauser
4f15267d3d [libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x
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
2023-02-15 16:52:25 +01:00
Nikolas Klauser
841399a218 [libc++] Add custom clang-tidy checks
Reviewed By: #libc, ldionne

Spies: jwakely, beanz, smeenai, cfe-commits, tschuett, avogelsgesang, Mordante, sstefan1, libcxx-commits, ldionne, mgorny, arichardson, miyuki

Differential Revision: https://reviews.llvm.org/D131963
2022-12-23 15:42:13 +01:00
Nikolas Klauser
d5e26775d0 [libc++] Granularize the rest of memory
Reviewed By: ldionne, #libc

Spies: vitalybuka, paulkirth, libcxx-commits, mgorny

Differential Revision: https://reviews.llvm.org/D132790
2022-09-05 12:36:41 +02:00
Mark de Wever
a595fcf9b4 [NFC][libc++][format] Renames __char_type concept.
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
2022-08-31 19:21:01 +02:00
Mark de Wever
f7c0df002a [libc++][format] Improve format buffer.
Allow bulk output operations on the buffer instead of adding one
code unit at a time. This has a huge performance benefit at the cost of
larger binary. This doesn't implement @vitaut's earlier suggestion to
avoid buffering for std::string when writing a strings. That can be done
in a follow-up patch.

There are some minor complications for the non-buffered format_to_n.
When writing one character at a time it's easy to detect when reaching
the limit n. This is solved by adding a small overhead for format_to_n.
When the next write would overflow it stores the data in the internal
buffer and copies that up-to n code units. The overhead isn't measured,
but it's expected to only be an issue for small values of n; for larger
values the general improvements will outweight the new overhead.

```
   text	   data	    bss	    dec	    hex	filename
 349081	   6096	    440	 355617	  56d21	format.libcxx.out-baseline
 344442	   6088	    440	 350970	  55afa	formatted_size.libcxx.out-baseline
4567980	  57272	    424	4625676	 46950c	formatter_float.libcxx.out-baseline
 718800	  12472	    488	 731760	  b2a70	formatter_int.libcxx.out-baseline
 376341	   6096	    552	 382989	  5d80d	format_to.libcxx.out-beaseline

 370169	   6096	    440	 376705	  5bf81	format.libcxx.out
 365530	   6088	    440	 372058	  5ad5a	formatted_size.libcxx.out
4575116	  57272	    424	4632812	 46b0ec	formatter_float.libcxx.out
 725936	  12472	    488	 738896	  b4650	formatter_int.libcxx.out
 397429	   6096	    552	 404077	  62a6d	format_to.libcxx.out
```

For very small strings the new method is slower, from 4 characters
there's already a small gain.

```
Comparing ./format.libcxx.out-baseline to ./format.libcxx.out
Benchmark                                           Time             CPU      Time Old      Time New       CPU Old       CPU New
--------------------------------------------------------------------------------------------------------------------------------
BM_format_string<char>/1                         +0.0268         +0.0268            43            44            43            44
BM_format_string<char>/2                         +0.0133         +0.0133            22            22            22            22
BM_format_string<char>/4                         -0.0248         -0.0248            12            11            12            11
BM_format_string<char>/8                         -0.0831         -0.0831             6             6             6             6
BM_format_string<char>/16                        -0.2976         -0.2976             4             3             4             3
BM_format_string<char>/32                        -0.4369         -0.4369             3             2             3             2
BM_format_string<char>/64                        -0.6375         -0.6375             3             1             3             1
BM_format_string<char>/128                       -0.7685         -0.7685             2             1             2             1

```

The int benchmark has benefits for the simple formatting, but shines for
the complex formatting:
```
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.2307         -0.2307            60            46            60            46
BM_Basic<int32_t>                                                    -0.1985         -0.1985            61            49            61            49
BM_Basic<uint64_t>                                                   -0.3478         -0.3479            81            53            81            53
BM_Basic<int64_t>                                                    -0.3475         -0.3475            81            53            81            53
BM_BasicLow<__uint128_t>                                             -0.3388         -0.3388            86            57            86            57
BM_BasicLow<__int128_t>                                              -0.3431         -0.3431            86            57            86            57
BM_Basic<__uint128_t>                                                -0.2822         -0.2822           236           170           236           170
BM_Basic<__int128_t>                                                 -0.3107         -0.3107           219           151           219           151
Integral_LocFalse_BaseBin_AlignNone_Int64                            -0.5781         -0.5781           178            75           178            75
Integral_LocFalse_BaseBin_AlignmentLeft_Int64                        -0.9231         -0.9231          1156            89          1156            89
Integral_LocFalse_BaseBin_AlignmentCenter_Int64                      -0.9179         -0.9179          1107            91          1107            91
Integral_LocFalse_BaseBin_AlignmentRight_Int64                       -0.9238         -0.9238          1147            87          1147            87
Integral_LocFalse_BaseBin_ZeroPadding_Int64                          -0.9170         -0.9170          1137            94          1137            94
Integral_LocFalse_BaseBin_AlignNone_Uint64                           -0.5923         -0.5923           175            71           175            71
Integral_LocFalse_BaseBin_AlignmentLeft_Uint64                       -0.9251         -0.9251          1154            86          1154            86
Integral_LocFalse_BaseBin_AlignmentCenter_Uint64                     -0.9204         -0.9204          1105            88          1105            88
Integral_LocFalse_BaseBin_AlignmentRight_Uint64                      -0.9242         -0.9242          1125            85          1125            85
Integral_LocFalse_BaseBin_ZeroPadding_Uint64                         -0.9232         -0.9232          1139            88          1139            88
Integral_LocFalse_BaseOct_AlignNone_Int64                            -0.3241         -0.3241           100            67           100            67
Integral_LocFalse_BaseOct_AlignmentLeft_Int64                        -0.9322         -0.9322          1166            79          1166            79
Integral_LocFalse_BaseOct_AlignmentCenter_Int64                      -0.9251         -0.9251          1108            83          1108            83
Integral_LocFalse_BaseOct_AlignmentRight_Int64                       -0.9303         -0.9303          1136            79          1136            79
Integral_LocFalse_BaseOct_ZeroPadding_Int64                          -0.9264         -0.9264          1156            85          1156            85
Integral_LocFalse_BaseOct_AlignNone_Uint64                           -0.3116         -0.3116            96            66            96            66
Integral_LocFalse_BaseOct_AlignmentLeft_Uint64                       -0.9310         -0.9310          1168            81          1168            81
Integral_LocFalse_BaseOct_AlignmentCenter_Uint64                     -0.9281         -0.9281          1128            81          1128            81
Integral_LocFalse_BaseOct_AlignmentRight_Uint64                      -0.9299         -0.9299          1148            80          1148            80
Integral_LocFalse_BaseOct_ZeroPadding_Uint64                         -0.9288         -0.9288          1153            82          1153            82
Integral_LocFalse_BaseDec_AlignNone_Int64                            -0.3342         -0.3342            95            63            95            63
Integral_LocFalse_BaseDec_AlignmentLeft_Int64                        -0.9360         -0.9360          1157            74          1157            74
Integral_LocFalse_BaseDec_AlignmentCenter_Int64                      -0.9303         -0.9303          1128            79          1128            79
Integral_LocFalse_BaseDec_AlignmentRight_Int64                       -0.9369         -0.9369          1164            73          1164            73
Integral_LocFalse_BaseDec_ZeroPadding_Int64                          -0.9323         -0.9323          1157            78          1157            78
Integral_LocFalse_BaseDec_AlignNone_Uint64                           -0.3198         -0.3198            93            63            93            63
Integral_LocFalse_BaseDec_AlignmentLeft_Uint64                       -0.9351         -0.9351          1158            75          1158            75
Integral_LocFalse_BaseDec_AlignmentCenter_Uint64                     -0.9298         -0.9298          1128            79          1128            79
Integral_LocFalse_BaseDec_AlignmentRight_Uint64                      -0.9361         -0.9361          1157            74          1157            74
Integral_LocFalse_BaseDec_ZeroPadding_Uint64                         -0.9333         -0.9333          1151            77          1151            77
Integral_LocFalse_BaseHex_AlignNone_Int64                            -0.3020         -0.3020            89            62            89            62
Integral_LocFalse_BaseHex_AlignmentLeft_Int64                        -0.9357         -0.9357          1174            75          1174            75
Integral_LocFalse_BaseHex_AlignmentCenter_Int64                      -0.9319         -0.9319          1129            77          1129            77
Integral_LocFalse_BaseHex_AlignmentRight_Int64                       -0.9350         -0.9350          1161            75          1161            75
Integral_LocFalse_BaseHex_ZeroPadding_Int64                          -0.9293         -0.9293          1150            81          1150            81
Integral_LocFalse_BaseHex_AlignNone_Uint64                           -0.3056         -0.3057            86            59            86            59
Integral_LocFalse_BaseHex_AlignmentLeft_Uint64                       -0.9378         -0.9378          1174            73          1174            73
Integral_LocFalse_BaseHex_AlignmentCenter_Uint64                     -0.9341         -0.9341          1129            74          1130            74
Integral_LocFalse_BaseHex_AlignmentRight_Uint64                      -0.9361         -0.9361          1157            74          1157            74
Integral_LocFalse_BaseHex_ZeroPadding_Uint64                         -0.9315         -0.9315          1147            79          1147            79
Integral_LocFalse_BaseHexUpper_AlignNone_Int64                       -0.0019         -0.0019            91            90            91            90
Integral_LocFalse_BaseHexUpper_AlignmentLeft_Int64                   -0.9099         -0.9099          1162           105          1162           105
Integral_LocFalse_BaseHexUpper_AlignmentCenter_Int64                 -0.9041         -0.9041          1121           108          1121           108
Integral_LocFalse_BaseHexUpper_AlignmentRight_Int64                  -0.9086         -0.9086          1162           106          1162           106
Integral_LocFalse_BaseHexUpper_ZeroPadding_Int64                     -0.9057         -0.9057          1164           110          1164           110
Integral_LocFalse_BaseHexUpper_AlignNone_Uint64                      +0.0110         +0.0110            86            87            86            87
Integral_LocFalse_BaseHexUpper_AlignmentLeft_Uint64                  -0.9136         -0.9136          1161           100          1161           100
Integral_LocFalse_BaseHexUpper_AlignmentCenter_Uint64                -0.9078         -0.9078          1133           104          1133           104
Integral_LocFalse_BaseHexUpper_AlignmentRight_Uint64                 -0.9132         -0.9132          1177           102          1177           102
Integral_LocFalse_BaseHexUpper_ZeroPadding_Uint64                    -0.9091         -0.9091          1160           105          1160           105
```
Other benchmarks give similar results.

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D129964
2022-08-16 18:54:10 +02:00
Mark de Wever
857a78c04d [libc++] Implements Unicode grapheme clustering
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
2022-07-20 18:38:32 +02:00
Mark de Wever
6589729206 [libc++][format] Improves parsing speed.
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
2022-07-13 17:39:09 +02:00
Mark de Wever
38adfa91a1 [libc++][format] Improve integral formatters.
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
2022-06-29 07:25:03 +02:00
Joe Loser
d2baefae68
[libc++] Replace _LIBCPP_HAS_NO_CONCEPTS with _LIBCPP_STD_VER > 17. NFCI.
All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly in
the tests, remove `// UNSUPPORTED: libcpp-no-concepts`.

Differential Revision: https://reviews.llvm.org/D121528
2022-03-13 12:32:06 -04:00
Louis Dionne
368faacac7 [libc++] Revert "Protect users from relying on detail headers" & related changes
This commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9,
which were related to the original commit). As landed, 5aaefa51 had
unintended consequences on some downstream bots and didn't have proper
coverage upstream due to a few subtle things. Implementing this is
something we should do in libc++, however we'll first need to address
a few issues listed in https://reviews.llvm.org/D106124#3349710.

Differential Revision: https://reviews.llvm.org/D120683
2022-03-01 08:20:24 -05:00
Christopher Di Bella
5aaefa510e [libcxx][modules] protects users from relying on detail headers
libc++ has started splicing standard library headers into much more
fine-grained content for maintainability. It's very likely that outdated
and naive tooling (some of which is outside of LLVM's scope) will
suggest users include things such as <__ranges/access.h> instead of
<ranges>, and Hyrum's law suggests that users will eventually begin to
rely on this without the help of tooling. As such, this commit
intends to protect users from themselves, by making it a hard error for
anyone outside of the standard library to include libc++ detail headers.

Differential Revision: https://reviews.llvm.org/D106124
2022-02-26 09:00:25 +00:00
Louis Dionne
f87aa19be6 [libc++] Move everything related solely to _LIBCPP_ASSERT to its own file
This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional change: it simply moves
_LIBCPP_ASSERT-related stuff to its own file so as to make it clear that
libc++ assertions and the debug mode are different things. Future patches
will make it possible to enable assertions without enabling the debug
mode.

Differential Revision: https://reviews.llvm.org/D119769
2022-02-16 12:49:50 -05:00
Nikolas Klauser
2a8f9a5e95 [libc++] Implement P0627R6 (Function to mark unreachable code)
Reviewed By: ldionne, Quuxplusone, #libc

Spies: arichardson, mstorsjo, libcxx-commits, mgorny

Differential Revision: https://reviews.llvm.org/D119152
2022-02-14 20:52:51 +01:00
Arthur O'Dwyer
fa6b9e4010 [libc++] Normalize all our '#pragma GCC system_header', and regression-test.
Now we'll notice if a header forgets to include this magic phrase.

Differential Revision: https://reviews.llvm.org/D118800
2022-02-04 12:27:19 -05:00
Mark de Wever
db2944e34b [libc++][format] Adds formatter floating-point.
This properly implements the formatter for floating-point types.

Completes:
- P1652R1 Printf corner cases in std::format
- LWG 3250 std::format: # (alternate form) for NaN and inf
- LWG 3243 std::format and negative zeroes

Implements parts of:
- P0645 Text Formatting

Reviewed By: #libc, ldionne, vitaut

Differential Revision: https://reviews.llvm.org/D114001
2022-01-24 18:12:24 +01:00
Arthur O'Dwyer
4d81a46f7f [libc++] Alphabetize header #includes. NFCI.
The NFC part of D116809. We still want to enforce this in CI,
but the mechanism for that is still to-be-determined.

Differential Revision: https://reviews.llvm.org/D116809
2022-01-10 16:30:38 -05:00
Mark de Wever
ed86610c7b [libc++][nfc] Move functions to a generic place.
This allows the floating-point formatter to use the same functions as
the integral formatter. This was tested in D114001.
2021-11-19 16:38:35 +01:00
Brian Cain
2d0aede515 [libcxx] Change the type of __size to correspond
__size was declared as unsigned which was compatible with
2021-11-12 08:30:38 -08:00
Mark de Wever
3e9689d72c [libc++][format] Adds integer formatter.
Implements the formatter for all fundamental integer types
(except `char`, `wchar_t`, and `bool`).
[format.formatter.spec]/2.3
For each charT, for each cv-unqualified arithmetic type ArithmeticT other
than char, wchar_t, char8_t, char16_t, or char32_t, a specialization
```
  template<> struct formatter<ArithmeticT, charT>;
```
This removes the stub implemented in D96664.

As an extension it adds partial support for 128-bit integer types.

Implements parts of:
- P0645 Text Formatting
- P1652 Printf corner cases in std::format

Completes:
- LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers

Reviewed By: #libc, ldionne, vitaut

Differential Revision: https://reviews.llvm.org/D103433
2021-10-07 17:07:51 +02:00