[libc++] Granularize some more type_traits

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

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

[libc++] Remove dead code and unneeded C++03 specializations from type_traits

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

[libc++] Disentangle _If, _Or and _And

Reviewed By: ldionne, #libc, EricWF

Spies: EricWF, libcxx-commits

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

[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++] Reduces std::to_chars instantiations.

Instead of instantiating all functions called by std::to_chars for the
integral types only instantiate them for 32 and 64 bit integral types.
This resu

[libc++] Reduces std::to_chars instantiations.

Instead of instantiating all functions called by std::to_chars for the
integral types only instantiate them for 32 and 64 bit integral types.
This results in a smaller binary when using different types.

In an example using the types: signed char, short, int, long, long long,
unsigned char, unsigned short, unsigned int, unsigned long, and
unsigned long long this saved 2792 bytes of code size. For libc++.so.1
is saves 688 bytes of code size (64-bit Linux).

This was discovered while investigating a solution for #52709.

Reviewed By: #libc, ldionne

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

show more ...

[libc++] Granularize some more of <type_traits>

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

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

[libc++] Remove uses of __two in type_traits

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

[libc++] Granularize even more of type_traits

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

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

[libc++] Fix conjunction/disjunction and mark a few LWG issues as complete

Fixes #54803
Fixes #53133

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

Differential Revision: https://revie

[libc++] Fix conjunction/disjunction and mark a few LWG issues as complete

Fixes #54803
Fixes #53133

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

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

show more ...

[libc++] Granularize more of <type_traits>

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

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

[libc++] type_traits: use __is_core_convertible in __invokable_r.

This fixes incorrect handling of non-moveable types, adding tests for this case.
See [issue 55346](https://github.com/llvm/llvm-proj

[libc++] type_traits: use __is_core_convertible in __invokable_r.

This fixes incorrect handling of non-moveable types, adding tests for this case.
See [issue 55346](https://github.com/llvm/llvm-project/issues/55346).

The current implementation is based on is_convertible, which is
[defined](https://timsong-cpp.github.io/cppwp/n4659/meta.rel#5) in terms of
validity of the following function:

```
To test() {
return declval<From>();
}
```

But this doesn't work if To and From are both some non-moveable type, which the
[definition](https://timsong-cpp.github.io/cppwp/n4659/conv#3) of implicit
conversions says should work due to guaranteed copy elision:

```
To to = E; // E has type From
```

It is this latter definition that is used in the
[definition](https://timsong-cpp.github.io/cppwp/n4659/function.objects#func.require-2)
of INVOKE<R>. Make __invokable_r use __is_core_convertible, which
captures the ability to use guaranteed copy elision, making the
definition correct for non-moveable types.

Fixes llvm/llvm-project#55346.

Reviewed By: #libc, philnik, EricWF

Spies: EricWF, jloser, ldionne, philnik, libcxx-commits

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

show more ...

[libc++] Granularize parts of <type_traits>

`<type_traits>` is quite a large header, so I'll granularize it in a few steps.

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

Differential

[libc++] Granularize parts of <type_traits>

`<type_traits>` is quite a large header, so I'll granularize it in a few steps.

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

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

show more ...

[libc++][ranges] Implement ranges::minmax and ranges::minmax_element

Reviewed By: var-const, #libc, ldionne

Spies: sstefan1, ldionne, BRevzin, libcxx-commits, mgorny

Differential Revision: https:/

[libc++][ranges] Implement ranges::minmax and ranges::minmax_element

Reviewed By: var-const, #libc, ldionne

Spies: sstefan1, ldionne, BRevzin, libcxx-commits, mgorny

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

show more ...

[libc++] Add __is_callable type trait and begin granularizing type_traits

`__is_callable` is required to ensure that the classic algorithms are only called with functions or functors. I also begin t

[libc++] Add __is_callable type trait and begin granularizing type_traits

`__is_callable` is required to ensure that the classic algorithms are only called with functions or functors. I also begin to granularize `<type_traits>`.

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

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

show more ...

[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++] Fix std::is_array<T[0]> and add tests

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

[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 the _LIBCPP_BOOL_CONSTANT macro

I suspect this is a remnant of the times when we were not comfortable
using Clang's C++11/14 extensions everywhere, but now we do, so we can
use _Bool

[libc++] Remove the _LIBCPP_BOOL_CONSTANT macro

I suspect this is a remnant of the times when we were not comfortable
using Clang's C++11/14 extensions everywhere, but now we do, so we can
use _BoolConstant instead and get rid of the macro.

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

show more ...

[libc++] Rename __identity to __type_identity

In C++20 the type trait `type_identity` was introduced. For the same purpose there is `__identity` for pre-C++20 code. The name is confusing, because si

[libc++] Rename __identity to __type_identity

In C++20 the type trait `type_identity` was introduced. For the same purpose there is `__identity` for pre-C++20 code. The name is confusing, because since C++20 there is also `identity`, which isn't a type trait.

Reviewed By: ldionne, Mordante, #libc

Spies: EricWF, libcxx-commits

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

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

Remove __uncvref; use __uncvref_t instead

Reviewed By: Quuxplusone, #libc

Spies: libcxx-commits

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

[libc++] Remove unused code paths for non-existent builtins

It looks like we added some checks to try and use builtin type traits
in https://reviews.llvm.org/D67900, but some of those type traits ar

[libc++] Remove unused code paths for non-existent builtins

It looks like we added some checks to try and use builtin type traits
in https://reviews.llvm.org/D67900, but some of those type traits are
never implemented as builtins, so this is essentially dead code.

Fixes llvm-project#53569

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

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