[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++] Format the code base (#74334)

This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmar

[libc++] Format the code base (#74334)

This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmarks, the test suite and remaining parts of the code. I'm
splitting this one into its own patch so the diff is a bit easier to
review.

This patch was generated with:

find libcxx/include libcxx/src -type f \
| grep -v 'module.modulemap.in' \
| grep -v 'CMakeLists.txt' \
| grep -v 'README.txt' \
| grep -v 'libcxx.imp' \
| grep -v '__config_site.in' \
| xargs clang-format -i

A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh
to help resolve merge and rebase issues across these formatting changes.

[1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all

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++] 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++] Rename the template arguments of the algorithm result types

Spies: libcxx-commits

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

[libc++] Canonicalize the ranges results and their tests

Reviewed By: var-const, Mordante, #libc, ldionne

Spies: ldionne, libcxx-commits

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

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

[libcxx] Wrap [[no_unique_address]] in a macro, for clang-cl

This should silence all remaining clang-cl build warnings.

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

[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++] [NFC] Normalize some `#ifndef _LIBCPP_HAS_NO_CONCEPTS`.

[libc++] Merge _LIBCPP_HAS_NO_RANGES into _LIBCPP_HAS_NO_CONCEPTS. NFC.

The macro that opts out of `std::ranges::` functionality is called
`_LIBCPP_HAS_NO_INCOMPLETE_RANGES`, and is unrelated to thi

[libc++] Merge _LIBCPP_HAS_NO_RANGES into _LIBCPP_HAS_NO_CONCEPTS. NFC.

The macro that opts out of `std::ranges::` functionality is called
`_LIBCPP_HAS_NO_INCOMPLETE_RANGES`, and is unrelated to this macro
which is specifically about _compiler_ support for the _syntax_.

The only non-mechanical diff here is in `<__config>`.

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

show more ...

[libc++] Add _LIBCPP_HIDE_FROM_ABI to in_in_result

Add `_LIBCPP_HIDE_FROM_ABI` to `in_in_result` conversion operators

Reviewed By: Quuxplusone, Mordante, #libc

Spies: libcxx-commits

Differential

[libc++] Add _LIBCPP_HIDE_FROM_ABI to in_in_result

Add `_LIBCPP_HIDE_FROM_ABI` to `in_in_result` conversion operators

Reviewed By: Quuxplusone, Mordante, #libc

Spies: libcxx-commits

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

show more ...

[libc++][ranges] Add ranges::in_in_result

Add `std::ranges::in_in_result`

Reviewed By: Quuxplusone, Mordante, #libc

Spies: ldionne, libcxx-commits, mgorny

Differential Revision: https://reviews.l

[libc++][ranges] Add ranges::in_in_result

Add `std::ranges::in_in_result`

Reviewed By: Quuxplusone, Mordante, #libc

Spies: ldionne, libcxx-commits, mgorny

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

show more ...