[libc++][NFC] Replace enable_if with __enable_if_t in a few places

Reviewed By: ldionne, #libc

Spies: jloser, libcxx-commits

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

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3158c604,
and 489637e66dd3. This should cover almost all the includes that had
been removed since LLVM 14 and that would contribute to breaking user
code when releasing LLVM 15.

It is possible to disable the inclusion of these headers by defining
_LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors will
enable that macro and start fixing downstream issues immediately. We
can then remove the macro (and the transitive includes) by default in
a future release. That way, we will break users only once by removing
transitive includes in bulk instead of doing it bit by bit a every
release, which is more disruptive for users.

Note 1: The set of headers to re-add was found by re-generating the
transitive include test on a checkout of release/14.x, which
provided the list of all transitive includes we used to provide.

Note 2: Several includes of <vector>, <optional>, <array> and <unordered_map>
have been added in this commit. These transitive inclusions were
added when we implemented boyer_moore_searcher in <functional>.

Note 3: This is a best effort patch to try and resolve downstream breakage
caused since branching LLVM 14. I wasn't able to perfectly mirror
transitive includes in LLVM 14 for a few headers, so I added a
release note explaining it. To summarize, adding boyer_moore_searcher
created a bunch of circular dependencies, so we have to break
backwards compatibility in a few cases.

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

show more ...

[libc++][NFC] Remove trailing whitespace

[libc++] P2321R2 section [tuple.tuple]. Adding C++23 constructors, assignment operators and swaps to `tuple`

1. for constructors that takes cvref variation of tuple<UTypes...>, there
used to be two

[libc++] P2321R2 section [tuple.tuple]. Adding C++23 constructors, assignment operators and swaps to `tuple`

1. for constructors that takes cvref variation of tuple<UTypes...>, there
used to be two SFINAE helper _EnableCopyFromOtherTuple,
_EnableMoveFromOtherTuple. And the implementations of these two helpers
seem to slightly differ from the spec. But now, we need 4 variations.
Instead of adding another two, this change refactored it to a single one
_EnableCtrFromUTypesTuple, which directly maps to the spec without
changing the C++11 behaviour. However, we need the helper __copy_cvref_t
to get the type of std::get<i>(cvref tuple<Utypes...>) for different
cvref, so I made __copy_cvref_t to be available in C++11.

2. for constructors that takes variations of std::pair, there used to be
four helpers _EnableExplicitCopyFromPair, _EnableImplicitCopyFromPair,
_EnableImplicitMoveFromPair, _EnableExplicitMoveFromPair. Instead of
adding another four, this change refactored into two helper
_EnableCtrFromPair and _BothImplicitlyConvertible. This also removes the
need to use _nat

3. for const member assignment operator, since the requirement is very
simple, I haven't refactored the old code but instead directly adding
the new c++23 code.

4. for const swap, I pretty much copy pasted the non-const version to make
these overloads look consistent

5. while doing these change, I found two of the old constructors wasn't
marked constexpr for C++20 but they should. fixed them and added unit
tests

Reviewed By: #libc, ldionne

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

show more ...

Revert "[libc++] P2321R2 section [tuple.tuple]. Adding C++23 constructors, assignment operators and swaps to `tuple`"

When merging the changes of <type_traits> header with the commits on
this header

Revert "[libc++] P2321R2 section [tuple.tuple]. Adding C++23 constructors, assignment operators and swaps to `tuple`"

When merging the changes of <type_traits> header with the commits on
this header over the last month, several conflicts were mistaken
resolved and the wrong branch was picked while resolving conflicts,
which leads to CI failure. In order to resolve the conflicts properly
with qualification CI job, this change is reverted.

This reverts commit 95733a55b986e73f4d8f5314e0d4557d8ae0b226.

show more ...

[libc++] P2321R2 section [tuple.tuple]. Adding C++23 constructors, assignment operators and swaps to `tuple`

1. for constructors that takes cvref variation of tuple<UTypes...>, there
used to be two

[libc++] P2321R2 section [tuple.tuple]. Adding C++23 constructors, assignment operators and swaps to `tuple`

1. for constructors that takes cvref variation of tuple<UTypes...>, there
used to be two SFINAE helper _EnableCopyFromOtherTuple,
_EnableMoveFromOtherTuple. And the implementations of these two helpers
seem to slightly differ from the spec. But now, we need 4 variations.
Instead of adding another two, this change refactored it to a single one
_EnableCtrFromUTypesTuple, which directly maps to the spec without
changing the C++11 behaviour. However, we need the helper __copy_cvref_t
to get the type of std::get<i>(cvref tuple<Utypes...>) for different
cvref, so I made __copy_cvref_t to be available in C++11.

2. for constructors that takes variations of std::pair, there used to be
four helpers _EnableExplicitCopyFromPair, _EnableImplicitCopyFromPair,
_EnableImplicitMoveFromPair, _EnableExplicitMoveFromPair. Instead of
adding another four, this change refactored into two helper
_EnableCtrFromPair and _BothImplicitlyConvertible. This also removes the
need to use _nat

3. for const member assignment operator, since the requirement is very
simple, I haven't refactored the old code but instead directly adding
the new c++23 code.

4. for const swap, I pretty much copy pasted the non-const version to make
these overloads look consistent

5. while doing these change, I found two of the old constructors wasn't
marked constexpr for C++20 but they should. fixed them and added unit
tests

Reviewed By: #libc, ldionne

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

show more ...

[libc++] Mark standard-mandated includes as such

Reviewed By: ldionne, Mordante, #libc, saugustine

Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman

Differential

[libc++] Mark standard-mandated includes as such

Reviewed By: ldionne, Mordante, #libc, saugustine

Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman

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

show more ...

[libc++] Removes unneeded includes.

This removes all "TODO: remove these headers" comments from our headers.

Note there seem to be more headers that can be removed, that will be
done in separate co

[libc++] Removes unneeded includes.

This removes all "TODO: remove these headers" comments from our headers.

Note there seem to be more headers that can be removed, that will be
done in separate commits.

Reviewed By: #libc, ldionne

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

show more ...

[libc++] Remove unused __functional includes

Reviewed By: ldionne, #libc

Spies: arichardson, smeenai, libcxx-commits, arphaman

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

[libc++] Remove redundant __invoke_constexpr functions

There are `constexpr` versions for the different `__invoke` functions, which seem to be identical other than begin `constexpr` since C++11 inst

[libc++] Remove redundant __invoke_constexpr functions

There are `constexpr` versions for the different `__invoke` functions, which seem to be identical other than begin `constexpr` since C++11 instead of being `constexpr` since C++20.

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

show more ...

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any publ

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.

It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.

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

show more ...

[libc++] Remove <utility> includes

Reviewed By: ldionne, Quuxplusone, #libc

Spies: libcxx-commits, arphaman

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

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

[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 `_LIBC

[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

show more ...

[libc++] Granularize <utility> includes

Reviewed By: ldionne, #libc

Spies: EricWF, libcxx-commits, arphaman

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

Remove __uncvref; use __uncvref_t instead

Reviewed By: Quuxplusone, #libc

Spies: libcxx-commits

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

[libc++] Remove __functional_base

Reviewed By: ldionne, Quuxplusone, #libc

Spies: Mordante, mgorny, libcxx-commits, arichardson, llvm-commits, arphaman

Differential Revision: https://reviews.llvm.

[libc++] Remove __functional_base

Reviewed By: ldionne, Quuxplusone, #libc

Spies: Mordante, mgorny, libcxx-commits, arichardson, llvm-commits, arphaman

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

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++] Guard bits of 598983d7 against _LIBCPP_HAS_NO_CONCEPTS.

[libc++] [NFC] s/_LIBCPP_STD_VER > 17 && !defined(_LIBCPP_HAS_NO_CONCEPTS)/!defined(_LIBCPP_HAS_NO_CONCEPTS)/

Per Discord discussion, we're normalizing on a simple `!defined(_LIBCPP_HAS_NO_CONCEPTS)

[libc++] [NFC] s/_LIBCPP_STD_VER > 17 && !defined(_LIBCPP_HAS_NO_CONCEPTS)/!defined(_LIBCPP_HAS_NO_CONCEPTS)/

Per Discord discussion, we're normalizing on a simple `!defined(_LIBCPP_HAS_NO_CONCEPTS)`
so that we can do a big search-and-replace for `!defined(_LIBCPP_HAS_NO_CONCEPTS)`
back into `_LIBCPP_STD_VER > 17` when we're ready to abandon support for concept-syntax-less
compilers.

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

show more ...

[libc++][P2321R2] Add specializations of basic_common_reference and common_type for tuple

Add specializations of `basic_common_reference` and `common_type` for `tuple`

Reviewed By: ldionne, Mordant

[libc++][P2321R2] Add specializations of basic_common_reference and common_type for tuple

Add specializations of `basic_common_reference` and `common_type` for `tuple`

Reviewed By: ldionne, Mordante, #libc

Spies: libcxx-commits

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

show more ...

[libc++][NFC] Update namespace comments in include/

update the namspace comments in include/

Reviewed By: ldionne, #libc

Spies: smeenai, libcxx-commits

Differential Revision: https://reviews.llvm

[libc++][NFC] Update namespace comments in include/

update the namspace comments in include/

Reviewed By: ldionne, #libc

Spies: smeenai, libcxx-commits

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

show more ...

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste st

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.

show more ...

[libc++] Remove _LIBCPP_HAS_NO_SPACESHIP_OPERATOR

All supported compilers support spaceship in C++20 nowadays.

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

[libc++][spaceship] Implement std::tuple::operator<=>

Implement parts of P1614, including three-way comparison for tuples, and expand testing.

Reviewed By: ldionne, Mordante, #libc

Differential Re

[libc++][spaceship] Implement std::tuple::operator<=>

Implement parts of P1614, including three-way comparison for tuples, and expand testing.

Reviewed By: ldionne, Mordante, #libc

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

show more ...