[libc++] Add missing includes of <cstddef>

(cherry picked from commit b1009bbd9e3d5acd85e92cb7f9a1109d2e72967c)

[libc++] Fix a hard error in `contiguous_iterator<NoOperatorArrowIter>`.

Evaluating `contiguous_iterator` on an iterator that satisfies all the
constraints except the `to_address` constraint and doe

[libc++] Fix a hard error in `contiguous_iterator<NoOperatorArrowIter>`.

Evaluating `contiguous_iterator` on an iterator that satisfies all the
constraints except the `to_address` constraint and doesn't have
`operator->` defined results in a hard error. This is because
instantiating `to_address` ends up instantiating templates
dependent on the given type which might lead to a hard error even
in a SFINAE context.

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

(cherry picked from commit 52d4c5016c4f8eca6abe84f658fc5f358bdfd2d0)

show more ...

[libc++] Implement P1004R2 (constexpr std::vector)

Reviewed By: #libc, ldionne

Spies: mgorny, var-const, ormris, philnik, miscco, hiraditya, steven_wu, jkorous, ldionne, christof, libcxx-commits

D

[libc++] Implement P1004R2 (constexpr std::vector)

Reviewed By: #libc, ldionne

Spies: mgorny, var-const, ormris, philnik, miscco, hiraditya, steven_wu, jkorous, ldionne, christof, libcxx-commits

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

(cherry picked from commit 98d3d5b5da66e3cf7807c23a0294280bb796466b)

show more ...

[libc++] Remove uses of __two in type_traits

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

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

[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

show more ...

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

[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

show more ...

[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/D1188

[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

show more ...

[libc++][NFC] Rename _EnableIf to __enable_if_t for consistency

In other places in the code, we use lowercase spelling for things that
are not available in prior standards.

Differential Revision: h

[libc++][NFC] Rename _EnableIf to __enable_if_t for consistency

In other places in the code, we use lowercase spelling for things that
are not available in prior standards.

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

show more ...

[libc++] Fix std::to_address(array).

There were basically two bugs here:

When C++20 `to_address` is called on `int arr[10]`, then `const _Ptr&` becomes
a reference to a const array, and then we dis

[libc++] Fix std::to_address(array).

There were basically two bugs here:

When C++20 `to_address` is called on `int arr[10]`, then `const _Ptr&` becomes
a reference to a const array, and then we dispatch to `__to_address<const int(&)[10]>`,
which, oops, gives us a `const int*` result instead of an `int*` result.
Solution: We need to provide the two standard-specified overloads of
`std::to_address` in exactly the same way that we provide two overloads
of `__to_address`.

When `__to_address` is called on a pointer type, `__to_address(const _Ptr&)`
is disabled so we successfully avoid trying to instantiate pointer_traits of
that pointer type. But when it's called on an array type, it's not disabled
for array types, so we go ahead and instantiate pointer_traits<int[10]>,
which goes boom. Solution: We need to disable `__to_address(const _Ptr&)`
for both pointer and array types. Also disable it for function types,
so that they get the nice error message; and put a test on it.

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

show more ...

[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs

Clang used to support [[nodebug]] everywhere except on typedefs. Since
we don't support such old Clangs a

[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs

Clang used to support [[nodebug]] everywhere except on typedefs. Since
we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE
in favour of always using _LIBCPP_NODEBUG.

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

show more ...

[libc++] Add missing space in (__map_value_compare&__y) etc. NFCI.

[libc++][NFC] Remove useless _LIBCPP_PUSH_MACROS

Only files that actually use min/max are required to do this dance.

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

[libcxx][iwyu] ensures we IWYU as prep for modules

This has been broken out of D104170 since it should be merged whether or
not we go ahead with the module map changes.

Differential Revision: https

[libcxx][iwyu] ensures we IWYU as prep for modules

This has been broken out of D104170 since it should be merged whether or
not we go ahead with the module map changes.

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

show more ...

Revert "[libcxx][module-map] creates submodules for private headers"

This reverts commit f1417eb9b1f51b689c78dd8cb0114c1749dd2845 as it
uncovered a Clang bug PR50592.

[libcxx][module-map] creates submodules for private headers

Most of our private headers need to be treated as submodules so that
Clang modules can export things correctly. Previous commits that spli

[libcxx][module-map] creates submodules for private headers

Most of our private headers need to be treated as submodules so that
Clang modules can export things correctly. Previous commits that split
monolithic headers into smaller chunks were unaware of this requirement,
and so this is being addressed in one fell swoop. Moving forward, most
new headers will need to have their own submodule (anything that's
conditionally included is exempt from this rule, which means `__support`
headers aren't made into submodules).

This hasn't been marked NFC, since I'm not 100% sure that's the case.

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

show more ...

[libc++] Rewrite std::to_address to avoid relying on element_type

This is a rough reapplication of the change that fixed std::to_address
to avoid relying on element_type (da456167). It is somewhat d

[libc++] Rewrite std::to_address to avoid relying on element_type

This is a rough reapplication of the change that fixed std::to_address
to avoid relying on element_type (da456167). It is somewhat different
because the fix to avoid breaking Clang (which caused it to be reverted
in 347f69c55) was a bit more involved.

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

show more ...

[libc++] Revert the std::to_address change to avoid relying on element_type.

This reverts commit da456167, which broke the Clang build. I'm able to
reproduce it but I want to give myself a bit more

[libc++] Revert the std::to_address change to avoid relying on element_type.

This reverts commit da456167, which broke the Clang build. I'm able to
reproduce it but I want to give myself a bit more time to investigate.

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

show more ...

[libc++] Make sure std::to_address doesn't depend on P::element_type.

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

[libc++] NFC: Normalize `#endif //` comment indentation

[libc++] Rationalize our treatment of contiguous iterators and __unwrap_iter().

- Implement C++20's changes to `reverse_iterator`, so that it won't be
accidentally counted as a contiguous iterat

[libc++] Rationalize our treatment of contiguous iterators and __unwrap_iter().

- Implement C++20's changes to `reverse_iterator`, so that it won't be
accidentally counted as a contiguous iterator in C++20 mode.
- Implement C++20's changes to `move_iterator` as well.
- `move_iterator` should not be contiguous. This fixes a bug where
we optimized `std::copy`-of-move-iterators in an observable way.
Add a regression test for that bugfix.
- Add libcxx tests for `__is_cpp17_contiguous_iterator` of all relevant
standard iterator types. Particularly check that vector::iterator
is still considered contiguous in all C++ modes, even C++03.

After this patch, there continues to be no supported way to write your
own iterator type in C++17-and-earlier such that libc++ will consider it
"contiguous"; however, we now fully support the C++20 approach (in C++20
mode only). If you want user-defined contiguous iterators in C++17-and-earlier,
libc++'s position is "please upgrade to C++20."

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

show more ...

[libc++] Split allocator_traits and pointer_traits out of <memory>

In addition to making the code a lot easier to grasp by localizing many
helper functions to the only file where they are actually n

[libc++] Split allocator_traits and pointer_traits out of <memory>

In addition to making the code a lot easier to grasp by localizing many
helper functions to the only file where they are actually needed, this
will allow creating helper functions that depend on allocator_traits
outside of <memory>.

This is done as part of implementing array support in allocate_shared,
which requires non-trivial array initialization algorithms that would be
better to keep out of <memory> for sanity. It's also a first step towards
splitting up our monolithic headers into finer grained ones, which will
make it easier to reuse functionality across the library. For example,
it's just weird that we had to define `addressof` inside <type_traits>
to avoid circular dependencies -- instead it's better to implement those
in true helper headers.

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

show more ...