[libc++] Complete the implementation of N4190

Fixes #37402

Reviewed By: ldionne

Spies: EricWF, avogelsgesang, libcxx-commits, arphaman

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

[libc++] Implement std::boyer_moore{, _horspool}_searcher

This mostly copys the `<experimental/functional>` stuff and updates the code to current libc++ style.

Reviewed By: ldionne, #libc

Spies: n

[libc++] Implement std::boyer_moore{, _horspool}_searcher

This mostly copys the `<experimental/functional>` stuff and updates the code to current libc++ style.

Reviewed By: ldionne, #libc

Spies: nlopes, adamdebreceni, arichardson, libcxx-commits, mgorny

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

show more ...

[libc++] Define legacy symbols for inline functions at a finer-grained level

When we build the library with the stable ABI, we need to include some
functions in the dylib that were made inline in la

[libc++] Define legacy symbols for inline functions at a finer-grained level

When we build the library with the stable ABI, we need to include some
functions in the dylib that were made inline in later versions of the
library (to avoid breaking code that might be relying on those symbols).

However, those methods were made non-inline whenever we'd be building
the library, which means that all translation units would end up using
the old out-of-line definition of these methods, as opposed to the new
inlined version. This patch makes it so that only the translation units
that actually define the out-of-line methods use the old definition,
opening up potential optimization opportunities in other translation
units.

This should solve some of the issues encountered in D65667.

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

show more ...

[libc++][NFC] Use noexcept instead of _NOEXCEPT for code compiled into the library

We build the library with C++20 anyways, so we can use noexcept directly.

[libc++] Support arrays in make_shared and allocate_shared (P0674R1)

This patch implements P0674R1, i.e. support for arrays in std::make_shared
and std::allocate_shared.

Co-authored-by: Zoe Carver

[libc++] Support arrays in make_shared and allocate_shared (P0674R1)

This patch implements P0674R1, i.e. support for arrays in std::make_shared
and std::allocate_shared.

Co-authored-by: Zoe Carver <[email protected]>

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

show more ...

[libc++] Make shared_ptr move unique_ptr's deleter

Addresses LWG 3548 which mandates that when shared_ptr is being constructed from a unique_ptr, the unique_ptr's deleter should be moved and not cop

[libc++] Make shared_ptr move unique_ptr's deleter

Addresses LWG 3548 which mandates that when shared_ptr is being constructed from a unique_ptr, the unique_ptr's deleter should be moved and not copied.

Reviewed By: #libc, philnik, EricWF

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

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++] Granularize <utility> includes

Reviewed By: ldionne, #libc

Spies: EricWF, libcxx-commits, arphaman

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

[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++] 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++] Replace includes of <utility> with specific detail headers

Basically a rebase of D104980; most of that patch had already happened
via gradual drive-by changes, but this finishes it up.
Don'

[libc++] Replace includes of <utility> with specific detail headers

Basically a rebase of D104980; most of that patch had already happened
via gradual drive-by changes, but this finishes it up.
Don't touch the inclusions from `<__functional_base>`, `<__hash_table>`,
or `<__locale>`; those could be removed if we propagated the
inclusions up to the includers of those files, but there are lots
of those includers.

`<algorithm>`, `<functional>`, and `<memory>` already include `<utility>`
at the top level. `<iterator>` did not, so I've added it there.

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

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++] Alphabetize header #includes. NFCI.

The NFC part of D116809. We still want to enforce this in CI,
but the mechanism for that is still to-be-determined.

Differential Revision: https://revie

[libc++] Alphabetize header #includes. NFCI.

The NFC part of D116809. We still want to enforce this in CI,
but the mechanism for that is still to-be-determined.

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

show more ...

[libc++] Enable <atomic> when threads are disabled

std::atomic is, for the most part, just a thin veneer on top of compiler
builtins. Hence, it should be available even when threads are not availabl

[libc++] Enable <atomic> when threads are disabled

std::atomic is, for the most part, just a thin veneer on top of compiler
builtins. Hence, it should be available even when threads are not available
on the system, and in fact there has been requests for such support.

This patch:
- Moves __libcpp_thread_poll_with_backoff to its own header so it can
be used in <atomic> when threads are disabled.
- Adds a dummy backoff policy for atomic polling that doesn't know about
threads.
- Adjusts the <atomic> feature-test macros so they are provided even when
threads are disabled.
- Runs the <atomic> tests when threads are disabled.

rdar://77873569

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

show more ...

[libc++] Implement shared_ptr methods inline in the class

This patch refactors the shared_ptr methods from being defined out-of-line
to being defined inline in the class, like what we do for all new

[libc++] Implement shared_ptr methods inline in the class

This patch refactors the shared_ptr methods from being defined out-of-line
to being defined inline in the class, like what we do for all new code in
the library. The benefits of doing that are that code is not as scattered
around and is hence easier to understand, and it avoids a ton of duplication
due to SFINAE checks. Defining the method where it is declared also removes
the possibility for mismatched attributes.

As a fly-by change, this also:

- Adds a few _LIBCPP_HIDE_FROM_ABI attributes
- Uses __enable_if_t instead of enable_if as a function argument, to match
the style that we use everywhere else.

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

show more ...

[libc++] LWG3001: add `remove_extent_t` to `weak_ptr::element_type`.

Also fix a few places in the `shared_ptr` implementation where
`element_type` was passed to the `__is_compatible` helper. This co

[libc++] LWG3001: add `remove_extent_t` to `weak_ptr::element_type`.

Also fix a few places in the `shared_ptr` implementation where
`element_type` was passed to the `__is_compatible` helper. This could
result in `remove_extent` being applied twice to the pointer's template
type (first by the definition of `element_type` and then by the helper),
potentially leading to somewhat less readable error messages for some
incorrect code.

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

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++] 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++][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

[libc++] Remove workarounds for the lack of deduction guides in C++17

All supported compilers have supported deduction guides in C++17 for a
while, so this isn't necessary anymore.

Differential Rev

[libc++] Remove workarounds for the lack of deduction guides in C++17

All supported compilers have supported deduction guides in C++17 for a
while, so this isn't necessary anymore.

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

show more ...

[libcxx][functional][modular] splices <functional> into modular headers

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