[libc++] Refactor the configuration macros to being always defined (#112094)

This is a follow-up to #89178. This updates the `<__config_site>`
macros.

[libc++][NFC] Replace _LIBCPP_NORETURN and TEST_NORETURN with [[noreturn]] (#80455)

`[[__noreturn__]]` is now always available, so we can simply use the
attribute directly instead of through a macr

[libc++][NFC] Replace _LIBCPP_NORETURN and TEST_NORETURN with [[noreturn]] (#80455)

`[[__noreturn__]]` is now always available, so we can simply use the
attribute directly instead of through a macro.

show more ...

[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
surpris

[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.

show more ...

[libc++] Properly define _LIBCPP_HAS_NO_UNICODE in __config_site (#95138)

Fixes #93638

Co-authored-by: Mark de Wever <koraq@xs4all.nl>

[libc++][format] Adds ABI tags to inline constexpr variables. (#86293)

This uses the macro on record types and inline constexpr variables. The
tagged declarations are very likely to change in futur

[libc++][format] Adds ABI tags to inline constexpr variables. (#86293)

This uses the macro on record types and inline constexpr variables. The
tagged declarations are very likely to change in future versions of
libc++:
- __fields are internal types used to control the formatter's parse
functions which fields to expect. Newer formatters may add new fields.
For example the filesystem::path formatter accepted in the recent Tokyo
meeting added a new 'g' flag, which differs from the 'g' type.
- The Unicode tables. The number of entries in these table likely differ
between Unicode versions. The tables contain only a part of all Unicode
properties. Typically they are stored in a 32-bit entry where some bits
contain the properties and other bits the size of the range. Changes in
the Unicode or C++ algorithms may require more properties to be
available in C++. This may affect the number of bits available in the
range. If needed, other declarations get the macro. This is mainly a
first time to review this approach.

This was originally https://reviews.llvm.org/D143494 where a new macro
_LIBCPP_HIDE_FROM_ABI_TYPE was defined. Testing revealed the existing
macro _LIBCPP_HIDE_FROM_ABI could be used. The "parts" of the macro that
do not affect records are not harmful. Based on this information the
existing macro was used and additional documentation was written.

show more ...

[libc++][format] Handle range-underlying-spec (#81914)

An immediate colon signifeis that the range-format-spec contains only
range-underlying-spec.

This patch allows this code to compile and run

[libc++][format] Handle range-underlying-spec (#81914)

An immediate colon signifeis that the range-format-spec contains only
range-underlying-spec.

This patch allows this code to compile and run:
```c++
std::println("{::<<9?}", std::span<const char>{"Hello", sizeof "Hello"});
```

show more ...

[libc++][format] Don't treat a closing '}' as part of format-spec (#81305)

This allows:
```
std::println("{}>42", std::thread::id{});
std::println("{}>42", std::span<int>{});
std::println("{}>42

[libc++][format] Don't treat a closing '}' as part of format-spec (#81305)

This allows:
```
std::println("{}>42", std::thread::id{});
std::println("{}>42", std::span<int>{});
std::println("{}>42", std::pair{42, "Hello"sv});
std::println("{:}>42", std::thread::id{});
std::println("{:}>42", std::span<int>{});
std::println("{:}>42", std::pair{42, "Hello"sv});
```
to compile and run.

show more ...

[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 neverthel

[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.

show more ...

[libc++][hardening] Categorize more 'valid-element-access' checks. (#71620)

[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 benchmar

[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

show more ...

[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

[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.

show more ...

[libc++] Make everything in namespace std have default type visibility and hidden visibility and remove _LIBCPP_ENUM_VIS

This avoids having to add `_LIBCPP_ENUM_VIS`, since that is handled through `

[libc++] Make everything in namespace std have default type visibility and hidden visibility and remove _LIBCPP_ENUM_VIS

This avoids having to add `_LIBCPP_ENUM_VIS`, since that is handled through `type_visibility` and GCC always makes the visibility of enums default. It also fixes and missing `_LIBCPP_EXPORTED_FROM_ABI` on classes when using Clang.

Reviewed By: ldionne, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D153658

show more ...

[libc++][format] Improves diagnostics.

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, bu

[libc++][format] Improves diagnostics.

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

show more ...

[libc++][format] Improves run-time diagnostics.

After parsing a std-format-spec it's validated, depending on the type used some
format options are not allowed. This improves the error messages in th

[libc++][format] Improves run-time diagnostics.

After parsing a std-format-spec it's validated, depending on the type used some
format options are not allowed. This improves the error messages in the
exceptions thrown upon failure.

Depends on D155364

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D155366

show more ...

[libc++][format] Improves compile-time diagnostics.

Then a std-format-spec option is invalid for a type the compile-time
validation will detect its usage and issue a diagnostic. Before it
validated

[libc++][format] Improves compile-time diagnostics.

Then a std-format-spec option is invalid for a type the compile-time
validation will detect its usage and issue a diagnostic. Before it
validated after parsing the entire std-format-spec, which meant the
diagnostic was less precise. It would be possible to do this validation
run-time but that has a performance overhead. When using the format
family of functions, this would be unneeded overhead; the validation was
done at run-time. For the vformat family it would give better
diagnostics.

To avoid paying what you don't use, it has been decided to aim for the
better performance. It's more likely users will use the format family of
functions.

Depends on D155264

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D155364

show more ...

[NFC][libc++][format] Generalizes bracket parsing.

Both the tuple formatter and range formatter parse a bracket. Instead of
implementing this twice do it in the generic parser. This is preparation
t

[NFC][libc++][format] Generalizes bracket parsing.

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

show more ...

[libc++][format] Removes unneeded includes.

I did a manual review after the post-review comments in D149543

Reviewed By: #libc, philnik, ldionne

Differential Revision: https://reviews.llvm.org/D15

[libc++][format] Removes unneeded includes.

I did a manual review after the post-review comments in D149543

Reviewed By: #libc, philnik, ldionne

Differential Revision: https://reviews.llvm.org/D154122

show more ...

[libc++][format] Implements formatting pointer.

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

[libc++][format] Implements formatting pointer.

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

show more ...

[libc++] Remove the legacy debug mode.

See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026

Reviewed By: #libc, Mordante, ldionne

Differential Revision: https://revi

[libc++] Remove the legacy debug mode.

See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026

Reviewed By: #libc, Mordante, ldionne

Differential Revision: https://reviews.llvm.org/D153672

show more ...

[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

[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

show more ...

[libc++] __iterator/readable_traits.h isn't standalone

`__iterator/readable_traits.h` can't be used by itself, intantiating `iter_value_t` requires `__iterator/iterator_traits.h`. `readable_traits.h

[libc++] __iterator/readable_traits.h isn't standalone

`__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

show more ...

[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. Origina

[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

show more ...

[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
d

[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

show more ...

[libc++][format] Improves width estimate.

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 Consid

[libc++][format] Improves width estimate.

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

show more ...

[libc++][format] Addresses LWG3720.

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:

[libc++][format] Addresses LWG3720.

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

show more ...