[libc++] Remove dedicated namespaces for ranges functions (#76543)

We originally put implementation-detail function objects into individual
namespaces for `std::ranges` without a good reason for do

[libc++] Remove dedicated namespaces for ranges functions (#76543)

We originally put implementation-detail function objects into individual
namespaces for `std::ranges` without a good reason for doing so. This
practice was continued, presumably because there was prior art. Since
there's no reason to keep these namespaces, this commit removes them,
which will slightly impact binary size.

This commit does not apply to CPOs, some of which need additional work.

show more ...

[libc++] Remove _LIBCPP_DISABLE_NODISCARD_EXTENSIONS and refactor the tests (#87094)

This also adds a few tests that were missing.

[libc++] Fix missing and incorrect push/pop macros (#79204)

We recently noticed that the unwrap_iter.h file was pushing macros, but
it was pushing them again instead of popping them at the end of t

[libc++] Fix missing and incorrect push/pop macros (#79204)

We recently noticed that the unwrap_iter.h file was pushing macros, but
it was pushing them again instead of popping them at the end of the
file. This led to libc++ basically swallowing any custom definition of
these macros in user code:

#define min HELLO
#include <algorithm>
// min is not HELLO anymore, it's not defined

While investigating this issue, I noticed that our push/pop pragmas were
actually entirely wrong too. Indeed, instead of pushing macros like
`move`, we'd push `move(int, int)` in the pragma, which is not a valid
macro name. As a result, we would not actually push macros like `move`
-- instead we'd simply undefine them. This led to the following code not
working:

#define move HELLO
#include <algorithm>
// move is not HELLO anymore

Fixing the pragma push/pop incantations led to a cascade of issues
because we use identifiers like `move` in a large number of places, and
all of these headers would now need to do the push/pop dance.

This patch fixes all these issues. First, it adds a check that we don't
swallow important names like min, max, move or refresh as explained
above. This is done by augmenting the existing
system_reserved_names.gen.py test to also check that the macros are what
we expect after including each header.

Second, it fixes the push/pop pragmas to work properly and adds missing
pragmas to all the files I could detect a failure in via the newly added
test.

rdar://121365472

show more ...

[libc++][NFC] Apply clang-format on large parts of the code base

This commit does a pass of clang-format over files in libc++ that
don't require major changes to conform to our style guide, or for
w

[libc++][NFC] Apply clang-format on large parts of the code base

This commit does a pass of clang-format over files in libc++ that
don't require major changes to conform to our style guide, or for
which we're not overly concerned about conflicting with in-flight
patches or hindering the git blame.

This roughly covers:
- benchmarks
- range algorithms
- concepts
- type traits

I did a manual verification of all the changes, and in particular I
applied clang-format on/off annotations in a few places where the
result was less readable after than before. This was not necessary
in a lot of places, however I did find that clang-format had pretty
bad taste when it comes to formatting concepts.

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

show more ...

[libc++] Change linkage for some functions.

Internal linkages fails when building libc++ with modules. Using
internal linkage is headers seems questionable to change the linkage.

Reviewed By: #libc

[libc++] Change linkage for some functions.

Internal linkages fails when building libc++ with modules. Using
internal linkage is headers seems questionable to change the linkage.

Reviewed By: #libc, philnik

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

show more ...

[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x

This change is almost fully mechanical. The only interesting change is in `generate_feature_test_macro_components.py` to generate

[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x

This change is almost fully mechanical. The only interesting change is in `generate_feature_test_macro_components.py` to generate `_LIBCPP_STD_VER >=` instead. To avoid churn in the git-blame this commit should be added to the `.git-blame-ignore-revs` once committed.

Reviewed By: ldionne, var-const, #libc

Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei

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

show more ...

[libc++] Add [[nodiscard]] extensions to ranges algorithms

This mirrors what we have done in the classic algorithms

Reviewed By: ldionne, #libc

Spies: libcxx-commits

Differential Revision: https:

[libc++] Add [[nodiscard]] extensions to ranges algorithms

This mirrors what we have done in the classic algorithms

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

show more ...

[libc++] Make <ranges> non-experimental

When we ship LLVM 16, <ranges> won't be considered experimental anymore.
We might as well do this sooner rather than later.

Differential Revision: https://re

[libc++] Make <ranges> non-experimental

When we ship LLVM 16, <ranges> won't be considered experimental anymore.
We might as well do this sooner rather than later.

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

show more ...

[libc++][ranges] Make range algorithms support proxy iterators

Also test all the range algorithms to verify the support.

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

[libc++][ranges] Implement ranges::min

Reviewed By: var-const, Mordante, #libc

Spies: jwakely, ldionne, libcxx-commits, mgorny

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

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

[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++] Guard much of std::ranges under _LIBCPP_HAS_NO_INCOMPLETE_RANGES.

The logic here is that we are disabling *only* things in `std::ranges::`.
Everything in `std::` is permitted, including `de

[libc++] Guard much of std::ranges under _LIBCPP_HAS_NO_INCOMPLETE_RANGES.

The logic here is that we are disabling *only* things in `std::ranges::`.
Everything in `std::` is permitted, including `default_sentinel`, `contiguous_iterator`,
`common_iterator`, `projected`, `swappable`, and so on. Then, we include
anything from `std::ranges::` that is required in order to make those things
work: `ranges::swap`, `ranges::swap_ranges`, `input_range`, `ranges::begin`,
`ranges::iter_move`, and so on. But then that's all. Everything else (including
notably all of the "views" and the `std::views` namespace itself) is still
locked up behind `_LIBCPP_HAS_NO_INCOMPLETE_RANGES`.

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

show more ...

[libc++][ranges] Implement ranges::min_element

Implement ranges::min_element

Reviewed By: Quuxplusone, Mordante, #libc

Spies: miscco, libcxx-commits, mgorny

Differential Revision: https://reviews

[libc++][ranges] Implement ranges::min_element

Implement ranges::min_element

Reviewed By: Quuxplusone, Mordante, #libc

Spies: miscco, libcxx-commits, mgorny

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

show more ...