[libc++] Switch experimental library macros to 0/1 macros (#124030)

This is a continuation of what's been started in #89178.

As a drive-by, this also changes the PSTL macro to say `EXPERIMENTAL`
in

[libc++] Switch experimental library macros to 0/1 macros (#124030)

This is a continuation of what's been started in #89178.

As a drive-by, this also changes the PSTL macro to say `EXPERIMENTAL`
instead of `INCOMPLETE`.

show more ...

[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454)

`__has_cpp_attribute(__nodiscard__)` is always true now, so we might as
well replace `_LIBCPP_NODISCARD`. It's one less macro that can r

[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454)

`__has_cpp_attribute(__nodiscard__)` is always true now, so we might as
well replace `_LIBCPP_NODISCARD`. It's one less macro that can result in
bad diagnostics.

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++][NFC] Fix typo in concept PSTL concept check

[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] Merge all frontend functions for the PSTL (#89219)

This is an intermediate step towards the PSTL dispatching mechanism
rework. It will make it a lot easier to track the upcoming fron

[libc++][pstl] Merge all frontend functions for the PSTL (#89219)

This is an intermediate step towards the PSTL dispatching mechanism
rework. It will make it a lot easier to track the upcoming front-end
changes. After the rework, there are basically no implementation details
in the front-end, so the definition of each algorithm will become much
simpler. Otherwise, it wouldn't make sense to define all the algorithms
in the same header.

show more ...