[libc++] Granularize <cstddef> includes (#108696)

[libc++] Guard PSTL headers with >= C++17 (#108234)

Otherwise we fail to build with modules in C++03 mode once we migrate to
a single top-level module, because those headers get pulled in but they

[libc++] Guard PSTL headers with >= C++17 (#108234)

Otherwise we fail to build with modules in C++03 mode once we migrate to
a single top-level module, because those headers get pulled in but they
don't compile as C++03.

show more ...

[libc++] Remove unnecessary #ifdef guards around PSTL implementation details (#95268)

We want the PSTL implementation details to be available regardless of
the Standard mode or whether the experime

[libc++] Remove unnecessary #ifdef guards around PSTL implementation details (#95268)

We want the PSTL implementation details to be available regardless of
the Standard mode or whether the experimental PSTL is enabled. This
patch guards the inclusion of the PSTL to the top-level headers that
define the public API in `__numeric` and `__algorithm`.

show more ...

[libc++] Overhaul the PSTL dispatching mechanism (#88131)

The experimental PSTL's current dispatching mechanism was designed with
flexibility in mind. However, while reviewing the in-progress OpenM

[libc++] Overhaul the PSTL dispatching mechanism (#88131)

The experimental PSTL's current dispatching mechanism was designed with
flexibility in mind. However, while reviewing the in-progress OpenMP
backend, I realized that the dispatching mechanism based on ADL and
default definitions in the frontend had several downsides. To name a
few:

1. The dispatching of an algorithm to the back-end and its default
implementation is bundled together via `_LIBCPP_PSTL_CUSTOMIZATION_POINT`.
This makes the dispatching really confusing and leads to annoyances
such as variable shadowing and weird lambda captures in the front-end.
2. The distinction between back-end functions and front-end algorithms
is not as clear as it could be, which led us to call one where we meant
the other in a few cases. This is bad due to the exception requirements
of the PSTL: calling a front-end algorithm inside the implementation of
a back-end is incorrect for exception-safety.
3. There are two levels of back-end dispatching in the PSTL, which treat
CPU backends as a special case. This was confusing and not as flexible
as we'd like. For example, there was no straightforward way to dispatch
all uses of `unseq` to a specific back-end from the OpenMP backend,
or for CPU backends to fall back on each other.

This patch rewrites the backend dispatching mechanism to solve these
problems, but doesn't touch any of the actual implementation of
algorithms. Specifically, this rewrite has the following
characteristics:

- There is a single level of backend dispatching, however partial backends can
be stacked to provide a full implementation of the PSTL. The two-level dispatching
that was used for CPU-based backends is handled by providing CPU-based basis
operations as simple helpers that can easily be reused when defining any PSTL
backend.

- The default definitions for algorithms are separated from their dispatching logic.

- The front-end is thus simplified a whole lot and made very consistent
for all algorithms, which makes it easier to audit the front-end for
things like exception-correctness, appropriate forwarding, etc.

Fixes #70718

show more ...

[libc++][pstl] Move the CPU algorithm implementations to __pstl (#89109)

This colocates the CPU algorithms closer to the rest of the PSTL
implementation details.

[libc++][pstl] Promote CPU backends to top-level backends (#88968)

This patch removes the two-level backend dispatching mechanism we had in
the PSTL. Instead of selecting both a PSTL backend and a

[libc++][pstl] Promote CPU backends to top-level backends (#88968)

This patch removes the two-level backend dispatching mechanism we had in
the PSTL. Instead of selecting both a PSTL backend and a PSTL CPU
backend, we now only select a top-level PSTL backend. This greatly
simplifies the PSTL configuration layer.

While this patch technically removes some flexibility from the PSTL
configuration mechanism because CPU backends are not considered
separately, it opens the door to a much more powerful configuration
mechanism based on chained backends in a follow-up patch.

This is a step towards overhauling the PSTL dispatching mechanism.

show more ...