[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++][NFC] Merge add_{const, cv, volatile}.h into a single header (#115610)

There isn't much benefit in having granular headers for only a few
simple lines of code.

[libc++][type_traits] P2674R1: A trait for implicit lifetime types (#106870)

Implements P2674R1: https://wg21.link/P2674R1

- https://eel.is/c++draft/type.traits
- https://eel.is/c++draft/meta.

[libc++][type_traits] P2674R1: A trait for implicit lifetime types (#106870)

Implements P2674R1: https://wg21.link/P2674R1

- https://eel.is/c++draft/type.traits
- https://eel.is/c++draft/meta.type.synop
- https://eel.is/c++draft/meta.unary.prop
- https://eel.is/c++draft/support.limits
- https://eel.is/c++draft/version.syn

Implementation details:
- Uses compiler intrinsic `__builtin_is_implicit_lifetime`:
- https://github.com/llvm/llvm-project/pull/101807
- Tests based on:
-
https://github.com/llvm/llvm-project/blob/d213981c80626698a07b11ce872acba098a863d4/clang/test/SemaCXX/type-traits.cpp#L1989

References:
- Implicit-lifetime
- Implicit-lifetime types [basic.types.general]/9:
https://eel.is/c++draft/basic.types.general
- Implicit-lifetime class [class.prop]/9:
https://eel.is/c++draft/class.prop
- P0593R6 Implicit creation of objects for low-level object
manipulation: https://wg21.link/P0593R6
- P1010R1 Container support for implicit lifetime types:
https://wg21.link/P1010R1
- P0593R6 Implicit creation of objects for low-level object
manipulation: https://wg21.link/P0593R6

Closes: #105259

---------

Co-authored-by: Hristo Hristov <zingam@outlook.com>

show more ...

[libc++][modules] Refactor poisoned_hash_helper (#108296)

The poisoned_hash_helper header was relying on an implicit forward
declaration of std::hash located in <type_traits>. When we improve the

[libc++][modules] Refactor poisoned_hash_helper (#108296)

The poisoned_hash_helper header was relying on an implicit forward
declaration of std::hash located in <type_traits>. When we improve the
modularization of the library, that causes issues, in addition to being
a fundamentally non-portable assumption in the test suite.

It turns out that the reason for relying on a forward declaration is to
be able to test that std::hash is *not* provided if we don't include any
header that provides it. But testing that is actually both non-portable
and not really useful.

Indeed, what harm does it make if additional headers provide std::hash
specializations? That would certainly be conforming -- the Standard
never requires an implementation to avoid providing a declaration when a
given header is included, instead it mandates what *must* be provided
for sure. In that spirit, it would be conforming for e.g. `<cstddef>` to
define the hash specializations if that was our desire. I also don't
read https://wg21.link/P0513R0 as going against that statement. Hence,
this patch just removes that test which doesn't carry its weight.

Fixes #56938

show more ...

[libc++] Implement P2985R0: std::is_virtual_base_of (#105847)

This trait is implemented in C++26 conditionally on the compiler
supporting the __builtin_is_virtual_base_of intrinsic. I believe only

[libc++] Implement P2985R0: std::is_virtual_base_of (#105847)

This trait is implemented in C++26 conditionally on the compiler
supporting the __builtin_is_virtual_base_of intrinsic. I believe only
tip-of-trunk Clang currently implements that builtin.

Closes #105432

show more ...

[libc++] Merge is_scoped_enum.h into is_enum.h (#99458)

[libc++] Include the rest of the detail headers by version in the umbrella headers (#96032)

This is a follow-up to #83740.

[libc++] Merge is_member{,_object,_function}_pointer.h (#98727)

The implementations for these traits have been simplified quite a bit,
since we have builtins available for them now.

[libc++][NFC] Replace __apply_cv with __copy_cv or __copy_cvref (#90867)

`__apply_cv_t` and `__copy_cvref_t` are very closely related. They are
in fact identical except that `__copy_cvref_t` handle

[libc++][NFC] Replace __apply_cv with __copy_cv or __copy_cvref (#90867)

`__apply_cv_t` and `__copy_cvref_t` are very closely related. They are
in fact identical except that `__copy_cvref_t` handles rvalue references
properly. Some uses don't actually require handling of references, so
they are replaced with `__copy_cv_t`.

show more ...

[libc++][NFC] Merge is{,_nothrow,_trivially}{,_copy,_move,_default}{_assignable,_constructible} (#85308)

These headers have become very small by using compiler builtins, often
containing only two d

[libc++][NFC] Merge is{,_nothrow,_trivially}{,_copy,_move,_default}{_assignable,_constructible} (#85308)

These headers have become very small by using compiler builtins, often
containing only two declarations. This merges these headers, since
there doesn't seem to be much of a benefit keeping them separate.

Specifically, `is_{,_nothrow,_trivially}{assignable,constructible}` are
kept and the `copy`, `move` and `default` versions of these type traits
are moved in to the respective headers.

show more ...

[libc++] Rename __fwd/hash.h to __fwd/functional.h and add reference_wrapper (#81445)

We forward declare `reference_wrapper` in multiple places already. This
moves the declaration to the canonical

[libc++] Rename __fwd/hash.h to __fwd/functional.h and add reference_wrapper (#81445)

We forward declare `reference_wrapper` in multiple places already. This
moves the declaration to the canonical place and removes unnecessary
includes of `__functional/reference_wrapper.h`.

show more ...

[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++] Untangles invoke.

The type traits parts are moved to a type_traits detail header.
This was discovered while working on modules.

Reviewed By: #libc, ldionne

Differential Revision: https://

[libc++] Untangles invoke.

The type traits parts are moved to a type_traits detail header.
This was discovered while working on modules.

Reviewed By: #libc, ldionne

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

show more ...

[libc++] Updates C++2b to C++23.

During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.

This updates the reference to c++2b to c++23 and updat

[libc++] Updates C++2b to C++23.

During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.

This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.

Note since we use clang-tidy 16 a small work-around is needed. Clang
knows -std=c++23 but clang-tidy not so for now force the lit compiler
flag to use -std=c++2b instead of -std=c++23.

Reviewed By: #libc, philnik, jloser, ldionne

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

show more ...

[libc++] Moves unwrap_reference to type_traits.

This was discovered while working on modules.

Reviewed By: #libc, philnik

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

[libc++] Implement P1413R3 (Deprecate std::aligned_storage and std::aligned_union)

There are no tests for the aliases because clang doesn't diagnose deprecated template aliases currently.

Reviewed

[libc++] Implement P1413R3 (Deprecate std::aligned_storage and std::aligned_union)

There are no tests for the aliases because clang doesn't diagnose deprecated template aliases currently.

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

show more ...

[libc++][format] Adds range-default-formatter.

This adds an incomplete version where the specializations for the
format_kinds are disabled dummy formatters.

Implements part of
- P2585R0 Improving d

[libc++][format] Adds range-default-formatter.

This adds an incomplete version where the specializations for the
format_kinds are disabled dummy formatters.

Implements part of
- P2585R0 Improving default container formatting

Reviewed By: ldionne, #libc

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

show more ...

[libc++] Granularize the rest of type_traits

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

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

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