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

[libc++] Re-apply LWG3870: Remove `voidify` (#110944)

This reverts commit f3d58f4161b86a479f68acb453e9622911c688a0.

Relands #110355.

Revert "[libc++] LWG3870: Remove `voidify` (#110355)" (#110587)

This reverts commit 78f9a8b82d772ff04a12ef95f2c9d31ee8f3e409.

This caused the LLDB test `TestDataFormatterGenericOptional.py` to fa

Revert "[libc++] LWG3870: Remove `voidify` (#110355)" (#110587)

This reverts commit 78f9a8b82d772ff04a12ef95f2c9d31ee8f3e409.

This caused the LLDB test `TestDataFormatterGenericOptional.py` to fail, and we need
a bit more time to look into it.

show more ...

[libc++] LWG3870: Remove `voidify` (#110355)

Instead of changing the cast sequence to implicit conversion in
_`voidify`_, I think it is better to totally remove `__voidify` and use
`static_cast` t

[libc++] LWG3870: Remove `voidify` (#110355)

Instead of changing the cast sequence to implicit conversion in
_`voidify`_, I think it is better to totally remove `__voidify` and use
`static_cast` to `void*`, which has equivalent effects.

Test coverage for const iterators are removed.

Now most affected algorithms are underconstrained, for which I submitted
[LWG3888](https://cplusplus.github.io/LWG/issue3888). I'm not sure
whether we should speculatively implement it at this moment, and thus
haven't added any `*.verify.cpp`.

In some control block types and `optional`, the stored objects are
changed to have cv-unqualified type.

Fixes #105119.

show more ...

[libc++] Fix several double-moves in the code base (#104616)

This patch hardens the "test iterators" we use to test algorithms by
ensuring that they don't get double-moved. As a result of this
har

[libc++] Fix several double-moves in the code base (#104616)

This patch hardens the "test iterators" we use to test algorithms by
ensuring that they don't get double-moved. As a result of this
hardening, the tests started reporting multiple failures where we would
double-move iterators, which are being fixed in this patch.

In particular:
- Fixed a double-move in pstl.partition
- Add coverage for begin()/end() in subrange tests
- Fix tests for ranges::ends_with and ranges::contains, which were
incorrectly calling begin() twice on the same subrange containing
non-copyable input iterators.

Fixes #100709

show more ...

[libc++] Remove the allocator<const T> extension (#96319)

This effort has quite a history:
- This was first attempted in 2022 via bed3240bf7d1, which broke
std::shared_ptr<T const> and caused the

[libc++] Remove the allocator<const T> extension (#96319)

This effort has quite a history:
- This was first attempted in 2022 via bed3240bf7d1, which broke
std::shared_ptr<T const> and caused the change to be reverted in
9138666f5464.
- We then re-attempted landing the change in 276ca87382b8 after fixing
std::shared_ptr, but reports were made that this broke code en masse
within Google. This led to the patch being reverted again in
a54d028895c9 with the goal to land this again with a migration path for
vendors.

This patch re-lands the removal while providing a migration path for
vendors by providing the `_LIBCPP_ENABLE_REMOVED_ALLOCATOR_CONST` macro.
This macro will be honored for the LLVM 19 release and will be removed
after that, at which point allocator<const T> will be removed
unconditionally.

Fixes #73665

show more ...

[libc++] Define _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER whenever we enable warnings in the test suite

This should make CI consistent on all the compilers we support. Most of
this patch is working around

[libc++] Define _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER whenever we enable warnings in the test suite

This should make CI consistent on all the compilers we support. Most of
this patch is working around various warnings emitted by GCC in our code
base, which are now being shown when we compile the tests.

After this patch, the whole test suite should be warning free on all
compilers we support and test, except for a few warnings on GCC that
we silence explicitly until we figure out the proper fix for them.

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

show more ...

Revert "[libc++] Remove extension to support allocator<const T>"

This reverts commit 276ca873. That commit has quite a history at this
point. It was first landed in dbc647643577, which broke std::sh

Revert "[libc++] Remove extension to support allocator<const T>"

This reverts commit 276ca873. That commit has quite a history at this
point. It was first landed in dbc647643577, which broke std::shared_ptr<T const>
and was reverted in 9138666f5. It was then re-applied in 276ca873, with
the std::shared_ptr issue fixed, but it caused widespread breakage at
Google (which suggests it would cause similar breakage in the wild too),
so now I'm reverting again.

Instead, I will add a escape hatch that vendors can turn on to enable
the extension and perform a phased transition over one or two releases
like we sometimes do when things become non-trivial.

show more ...

[libc++] Remove extension to support allocator<const T>

This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
imple

[libc++] Remove extension to support allocator<const T>

This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
implementations to reject std::allocator<cv T>, so allowing it is
really going against the current.

This was discovered in D120684: this extension required `const_cast`ing
in `__construct_range_forward`, a fishy bit of code that can be removed
if we don't support the extension anymore.

This is a re-application of dbc647643577, which was reverted in 9138666f5
because it broke std::shared_ptr<T const>. Tests have now been added and
we've made sure that std::shared_ptr<T const> wouldn't be broken in this
version.

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

show more ...

Revert "[libc++] Remove extension to support allocator<const T>"

This reverts commit bed3240bf7d196a17cc31f1c5b59b4721017e638.

I will need to add more tests for std::shared_ptr<T const> before
re-l

Revert "[libc++] Remove extension to support allocator<const T>"

This reverts commit bed3240bf7d196a17cc31f1c5b59b4721017e638.

I will need to add more tests for std::shared_ptr<T const> before
re-landing this.

show more ...

[libc++] Remove extension to support allocator<const T>

This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
imple

[libc++] Remove extension to support allocator<const T>

This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
implementations to reject std::allocator<cv T>, so allowing it is
really going against the current.

This was discovered in D120684: this extension required `const_cast`ing
in `__construct_range_forward`, a fishy bit of code that can be removed
if we don't support the extension anymore.

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

show more ...

[libc++][ranges] Implement `construct_at` and `destroy{,_at}`.

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

[libc++] Remove test-suite annotations for unsupported Clang versions

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

[libc++] Skip tests using constexpr destructors with older clang versions

It appears that the released version of clang that supports constexpr
destructors is clang 10 and the oldest one that accept

[libc++] Skip tests using constexpr destructors with older clang versions

It appears that the released version of clang that supports constexpr
destructors is clang 10 and the oldest one that accepts -std=c++2a is 5,
so mark these as UNSUPPORTED for clang-5 to clang-9.

Reviewed By: #libc, ldionne

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

show more ...

[libc++] Fix constexpr dynamic allocation on GCC 10

We're technically not allowed by the Standard to call ::operator new in
constexpr functions like __libcpp_allocate. Clang doesn't seem to complain

[libc++] Fix constexpr dynamic allocation on GCC 10

We're technically not allowed by the Standard to call ::operator new in
constexpr functions like __libcpp_allocate. Clang doesn't seem to complain
about it, but GCC does.

show more ...

[libc++] Implement C++20's P0784 (More constexpr containers)

This commit adds std::construct_at, and marks various members of
std::allocator_traits and std::allocator as constexpr. It also adds
test

[libc++] Implement C++20's P0784 (More constexpr containers)

This commit adds std::construct_at, and marks various members of
std::allocator_traits and std::allocator as constexpr. It also adds
tests and turns the existing tests into hybrid constexpr/runtime tests.

Thanks to Richard Smith for initial work on this, and to Michael Park
for D69803, D69132 and D69134, which are superseded by this patch.

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

show more ...