[libc++] Fix ambiguity due to non-uglified member typedefs (#121664)

This PR fixes the ambiguities in name lookup caused by non-standard
member typedefs `size_type` and `difference_type` in `std::b

[libc++] Fix ambiguity due to non-uglified member typedefs (#121664)

This PR fixes the ambiguities in name lookup caused by non-standard
member typedefs `size_type` and `difference_type` in `std::bitset`.

Follows up #121620.
Closes #121618.

show more ...

[libc++] Uglify non-standard member typedef const_reference in bitset (#121620)

According to
[[template.bitset.general]](https://eel.is/c++draft/template.bitset.general),
`std::bitset` is supposed

[libc++] Uglify non-standard member typedef const_reference in bitset (#121620)

According to
[[template.bitset.general]](https://eel.is/c++draft/template.bitset.general),
`std::bitset` is supposed to have only
one (public) member typedef, `reference`. However, libc++'s
implementation of `std::bitset` offers more that that. Specifically, it
offers a public typedef `const_reference` and two private typedefs
`size_type` and `difference_type`. These non-standard member typedefs,
despite being private, can cause potential ambiguities in name lookup in
user-defined classes, as demonstrated in issue #121618.

Fixing the public member typedef `const_reference` is straightforward:
we can simply replace it with an `__ugly_name` such as
`__const_reference`. However, fixing the private member typedefs
`size_type` and `difference_type` is not so straightforward as they are
required by the `__bit_iterator` class and the corresponding algorithms
optimized for `__bit_iterator`s (e.g., `ranges::fill`).

This PR fixes the member typedef `const_reference` by using uglified
name for it. Further work will be undertaken to address `size_type` and
`difference_type`.

Follows up #80706, #111127, and #112843,

show more ...

[libc++][hardening] Add a bounds check for `valarray` and `bitset`. (#120685)

Add a `valid-element-access` check to `valarray::operator[]` and
`bitset::operator[]`.

[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)

This patch implements the forwarding to frozen C++03 headers as
discussed in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-

[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)

This patch implements the forwarding to frozen C++03 headers as
discussed in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the
RFC, we initially proposed selecting the right headers from the Clang
driver, however consensus seemed to steer towards handling this in the
library itself. This patch implements that direction.

At a high level, the changes basically amount to making each public
header look like this:

```
// inside <vector>
#ifdef _LIBCPP_CXX03_LANG
# include <__cxx03/vector>
#else
// normal <vector> content
#endif
```

In most cases, public headers are simple umbrella headers so there isn't
much code in the #else branch. In other cases, the #else branch contains
the actual implementation of the header.

show more ...

[libc++] Add #if 0 block to all the top-level headers (#119234)

Including The frozen C++03 headers results in a lot of formatting
changes in the main headers, so this splits these changes into a
sep

[libc++] Add #if 0 block to all the top-level headers (#119234)

Including The frozen C++03 headers results in a lot of formatting
changes in the main headers, so this splits these changes into a
separate commit instead.

This is part of
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.

show more ...

[libc++] Granularize <cstddef> includes (#108696)

[libc++] __uglify non-conforming member typedef `base` (#112843)

Currently, libc++'s `bitset`, `forward_list`, and `list` have
non-conforming member typedef name `base`. The typedef is private, but

[libc++] __uglify non-conforming member typedef `base` (#112843)

Currently, libc++'s `bitset`, `forward_list`, and `list` have
non-conforming member typedef name `base`. The typedef is private, but
can cause ambiguity in name lookup.

Some other classes in libc++ that are either implementation details or
not precisely specified by the standard also have member typdef `base`.
I think this can still be conforming.

Follows up #80706 and #111127.

show more ...

[libc++] __uglify internal member names of iterators in `bitset` (#111127)

[template.bitset.general] indicates that `bitset` shouldn't have member
typedef-names `iterator` and `const_iterator`. Cur

[libc++] __uglify internal member names of iterators in `bitset` (#111127)

[template.bitset.general] indicates that `bitset` shouldn't have member
typedef-names `iterator` and `const_iterator`. Currently libc++'s
typedef-names are causing ambiguity in name lookup, which isn't
conforming.

As these iterator types are themselves useful, I think we should just
use __uglified member typedef-names for them.

Fixes #111125

show more ...

[libc++][modules] Fix missing and incorrect includes (#108850)

This patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to

[libc++][modules] Fix missing and incorrect includes (#108850)

This patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to move
towards a mostly monolithic top-level std module.

show more ...

[libc++] Fix failures with GCC 14 (#92663)

Fixes #91831

[libc++] Clean up includes of <__assert> (#80091)

Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
th

[libc++] Clean up includes of <__assert> (#80091)

Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
that mechanism anymore, we don't need to declare __libcpp_verbose_abort
from all public headers, and we can clean up a lot of unnecessary
includes.

This patch also moves the definition of the various assertion categories
to the <__assert> header, since we now rely on regular IWYU for these
assertion macros.

rdar://105510916

show more ...

[libc++] Refactor more __enable_ifs to the canonical style (#81457)

This brings the code base closer to having only a single style of
`enable_if`s.

[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++][NFC] Add a few clang-format annotations (#74352)

This is in preparation for clang-formatting the whole code base. These
annotations are required either to avoid clang-format bugs or becaus

[libc++][NFC] Add a few clang-format annotations (#74352)

This is in preparation for clang-formatting the whole code base. These
annotations are required either to avoid clang-format bugs or because
the manually formatted code is significantly more readable than the
clang-formatted alternative. All in all, it seems like very few
annotations are required, which means that clang-format is doing a very
good job in most cases.

show more ...

[libc++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)

In preparation for running clang-format on the whole code base, we are
also removing mentions of the legacy _LIBCPP_INLIN

[libc++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)

In preparation for running clang-format on the whole code base, we are
also removing mentions of the legacy _LIBCPP_INLINE_VISIBILITY macro in
favor of the newer _LIBCPP_HIDE_FROM_ABI.

We're still leaving the definition of _LIBCPP_INLINE_VISIBILITY to avoid
creating needless breakage in case some older patches are checked-in
with mentions of the old macro. After we branch for LLVM 18, we can do
another pass to clean up remaining uses of the macro that might have
gotten introduced by mistake (if any) and remove the macro itself at the
same time. This is just a minor convenience to smooth out the transition
as much as possible.

See
https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.

show more ...

[libc++] Optimize ranges::count for __bit_iterators

```
---------------------------------------------------------------
Benchmark old new
--------------

[libc++] Optimize ranges::count for __bit_iterators

```
---------------------------------------------------------------
Benchmark old new
---------------------------------------------------------------
bm_vector_bool_count/1 1.92 ns 1.92 ns
bm_vector_bool_count/2 1.92 ns 1.92 ns
bm_vector_bool_count/3 1.92 ns 1.92 ns
bm_vector_bool_count/4 1.92 ns 1.92 ns
bm_vector_bool_count/5 1.92 ns 1.92 ns
bm_vector_bool_count/6 1.92 ns 1.92 ns
bm_vector_bool_count/7 1.92 ns 1.92 ns
bm_vector_bool_count/8 1.92 ns 1.92 ns
bm_vector_bool_count/16 1.92 ns 1.92 ns
bm_vector_bool_count/64 2.24 ns 2.25 ns
bm_vector_bool_count/512 3.19 ns 3.20 ns
bm_vector_bool_count/4096 14.1 ns 12.3 ns
bm_vector_bool_count/32768 84.0 ns 83.6 ns
bm_vector_bool_count/262144 664 ns 661 ns
bm_vector_bool_count/1048576 2623 ns 2628 ns
bm_vector_bool_ranges_count/1 1.07 ns 1.92 ns
bm_vector_bool_ranges_count/2 1.65 ns 1.92 ns
bm_vector_bool_ranges_count/3 2.27 ns 1.92 ns
bm_vector_bool_ranges_count/4 2.68 ns 1.92 ns
bm_vector_bool_ranges_count/5 3.33 ns 1.92 ns
bm_vector_bool_ranges_count/6 3.99 ns 1.92 ns
bm_vector_bool_ranges_count/7 4.67 ns 1.92 ns
bm_vector_bool_ranges_count/8 5.19 ns 1.92 ns
bm_vector_bool_ranges_count/16 11.1 ns 1.92 ns
bm_vector_bool_ranges_count/64 52.2 ns 2.24 ns
bm_vector_bool_ranges_count/512 452 ns 3.20 ns
bm_vector_bool_ranges_count/4096 3577 ns 12.1 ns
bm_vector_bool_ranges_count/32768 28725 ns 83.7 ns
bm_vector_bool_ranges_count/262144 229676 ns 662 ns
bm_vector_bool_ranges_count/1048576 905574 ns 2625 ns
```

Reviewed By: #libc, ldionne

Spies: arichardson, ldionne, libcxx-commits

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

show more ...

[libc++] Adds string_view constructor overload

Implements
- P2697R1 Interfacing bitset with string_view

Depends on D153192

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.

[libc++] Adds string_view constructor overload

Implements
- P2697R1 Interfacing bitset with string_view

Depends on D153192

Reviewed By: #libc, ldionne

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

show more ...

[libc++] Optimize ranges::find for vector<bool>

Benchmark results:
```
----------------------------------------------------------------
Benchmark old n

[libc++] Optimize ranges::find for vector<bool>

Benchmark results:
```
----------------------------------------------------------------
Benchmark old new
----------------------------------------------------------------
bm_vector_bool_ranges_find/1 5.64 ns 6.08 ns
bm_vector_bool_ranges_find/2 16.5 ns 6.03 ns
bm_vector_bool_ranges_find/3 20.3 ns 6.07 ns
bm_vector_bool_ranges_find/4 22.2 ns 6.08 ns
bm_vector_bool_ranges_find/5 23.5 ns 6.05 ns
bm_vector_bool_ranges_find/6 24.4 ns 6.10 ns
bm_vector_bool_ranges_find/7 26.7 ns 6.10 ns
bm_vector_bool_ranges_find/8 25.0 ns 6.08 ns
bm_vector_bool_ranges_find/16 27.9 ns 6.07 ns
bm_vector_bool_ranges_find/64 44.5 ns 5.35 ns
bm_vector_bool_ranges_find/512 243 ns 25.7 ns
bm_vector_bool_ranges_find/4096 1858 ns 35.6 ns
bm_vector_bool_ranges_find/32768 15461 ns 93.5 ns
bm_vector_bool_ranges_find/262144 126462 ns 571 ns
bm_vector_bool_ranges_find/1048576 497736 ns 2272 ns
```

Reviewed By: #libc, Mordante

Spies: var-const, Mordante, libcxx-commits

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

show more ...

[libc++] Simplify single-iterator __bit_iterator algorithm specializations

The single-iterator algorithms have an implementation for `false` and `true`, which are almost identical. Instead of writin

[libc++] Simplify single-iterator __bit_iterator algorithm specializations

The single-iterator algorithms have an implementation for `false` and `true`, which are almost identical. Instead of writing two functions, this refactors the code to take the value searched for as a template parameter. This avoids a lot of code duplication and makes it easier to reason about the algorithm and their difference.

Reviewed By: #libc, Mordante

Spies: Mordante, libcxx-commits

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

show more ...

[NFC][libc++][bitset] Refactors constructors.

Based on the review comments in D153201 this combines the string and
c-string constructors. The common constructor is using a string_view:
- it allows p

[NFC][libc++][bitset] Refactors constructors.

Based on the review comments in D153201 this combines the string and
c-string constructors. The common constructor is using a string_view:
- it allows propagating the _Traits, which are required to be used for
comparison.
- it avoids allocating
- libc++ supports it in C++03

Reviewed By: philnik, #libc, ldionne

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

show more ...

[libc++][spaceship] P1612R2: Removed `operator!=` from `bitset`

Implements parts of P1612R2:
- Removed `operator!=` from `bitset`

Reviewed By: #libc, Mordante

Differential Revision: https://review

[libc++][spaceship] P1612R2: Removed `operator!=` from `bitset`

Implements parts of P1612R2:
- Removed `operator!=` from `bitset`

Reviewed By: #libc, Mordante

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

show more ...

[libc++] Remove <cstdlib> includes

We changed the `abort` calls when trying to throw exceptions in `-fno-exceptions` mode to `__verbose_abort` calls, which removes the dependency in most files.

Rev

[libc++] Remove <cstdlib> includes

We changed the `abort` calls when trying to throw exceptions in `-fno-exceptions` mode to `__verbose_abort` calls, which removes the dependency in most files.

Reviewed By: ldionne, #libc

Spies: dim, emaste, mikhail.ramalho, smeenai, libcxx-commits

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

show more ...

[libc++] Granularize <type_traits> includes

Reviewed By: ldionne, #libc, #libc_abi

Spies: #libc_vendors, smeenai, libcxx-commits

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

[libc++] Enable radability-identifier-naming for local variables and fix any problems

Fixes #60658

Reviewed By: Mordante, #libc

Spies: aheejin, sstefan1, libcxx-commits

Differential Revision: htt

[libc++] Enable radability-identifier-naming for local variables and fix any problems

Fixes #60658

Reviewed By: Mordante, #libc

Spies: aheejin, sstefan1, libcxx-commits

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

show more ...