[libc++] Refactor the configuration macros to being always defined (#112094)

This is a follow-up to #89178. This updates the `<__config_site>`
macros.

[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++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)

In preparation for running clang-format on the whole code base, we are
also removing mentions of the legacy _LIBCPP_INLIN

[libc++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)

In preparation for running clang-format on the whole code base, we are
also removing mentions of the legacy _LIBCPP_INLINE_VISIBILITY macro in
favor of the newer _LIBCPP_HIDE_FROM_ABI.

We're still leaving the definition of _LIBCPP_INLINE_VISIBILITY to avoid
creating needless breakage in case some older patches are checked-in
with mentions of the old macro. After we branch for LLVM 18, we can do
another pass to clean up remaining uses of the macro that might have
gotten introduced by mistake (if any) and remove the macro itself at the
same time. This is just a minor convenience to smooth out the transition
as much as possible.

See
https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.

show more ...

[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI

These macros are always defined identically, so we can simplify the code a bit by merging t

[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI

These macros are always defined identically, so we can simplify the code a bit by merging them.

Reviewed By: ldionne, #libc

Spies: libcxx-commits, krytarowski, smeenai

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

show more ...

[libc++] Add hide_from_abi check for classes

We already have a clang-tidy check for making sure that `_LIBCPP_HIDE_FROM_ABI` is on free functions. This patch extends this to class members. The place

[libc++] Add hide_from_abi check for classes

We already have a clang-tidy check for making sure that `_LIBCPP_HIDE_FROM_ABI` is on free functions. This patch extends this to class members. The places where we don't check for `_LIBCPP_HIDE_FROM_ABI` are classes for which we have an instantiation in the library.

Reviewed By: ldionne, Mordante, #libc

Spies: jplehr, mikhail.ramalho, sstefan1, libcxx-commits, krytarowski, miyuki, smeenai

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

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 warning pragmas

This makes the GCC output even cleaner!

Reviewed By: ldionne, #libc

Spies: mstorsjo, Quuxplusone, Mordante, libcxx-commits

Differential Revision: https://reviews.ll

[libc++] Guard warning pragmas

This makes the GCC output even cleaner!

Reviewed By: ldionne, #libc

Spies: mstorsjo, Quuxplusone, Mordante, libcxx-commits

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

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++] Start using `arc4random()` to implement `std::random_device` on Apple

On Apple platforms, arc4random is faster than /dev/urandom, and it is
the recommended user-space RNG according to Apple

[libc++] Start using `arc4random()` to implement `std::random_device` on Apple

On Apple platforms, arc4random is faster than /dev/urandom, and it is
the recommended user-space RNG according to Apple's own OS folks.

This commit adds an ABI switch to guard ABI-break-protections in
std::random_device, and starts using arc4random instead of /dev/urandom
to implement std::random_device on Apple platforms.

Note that previously, `std::random_device` would allow passing a custom
token to its constructor, and that token would be interpreted as the name
of a file to read entropy from. This was implementation-defined and
undocumented. After this change, Apple platforms will be using arc4random()
instead, and any custom token passed to the constructor will be ignored.
This behavioral change will also impact other platforms that use the
arc4random() implementation, such as OpenBSD. This should be fine since
that is effectively a relaxation of the constructor's requirements.

rdar://86638350

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

show more ...

[libc++] Partially revert 346ef5e5879e

This moves the macro definitions back to __config, but keeps the
improved documentation. 346ef5e5879e had broken the MinGW build.

[libc++][NFC] Improve documentation of the various random_device implementations

Also, move the setting of the macro closer to its point of use, which
also has the benefit of uncluttering `__config`.

[libc++][NFC] Reformatting in random_device.h and random.cpp

[libc++] `= delete` member functions with // = delete;

Use `= delete` for member functions that are marked with `// = delete;`

Reviewed By: ldionne, Quuxplusone, #libc

Spies: jloser, libcxx-commit

[libc++] `= delete` member functions with // = delete;

Use `= delete` for member functions that are marked with `// = delete;`

Reviewed By: ldionne, Quuxplusone, #libc

Spies: jloser, libcxx-commits

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

show more ...

[libc++] Granularize the <random> header. NFCI.

Actually there's one functional change here, which is that users can
no longer depend on <random> to include all of C++20 <concepts>. That
inclusion i

[libc++] Granularize the <random> header. NFCI.

Actually there's one functional change here, which is that users can
no longer depend on <random> to include all of C++20 <concepts>. That
inclusion is so new that we believe nobody should be depending on it
yet, even in the presence of Hyrum's Law. We keep the includes of <vector>,
<algorithm>, etc., so as not to break pre-C++20 Hyrum's Law users.

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

show more ...