[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++] Change _LIBCPP_CONSTEXPR_SINCE_XXX to constexpr in the dylib

Since we build the dylib with C++20, there's no need to use conditional
macros anymore.

Differential Revision: https://reviews.

[libc++] Change _LIBCPP_CONSTEXPR_SINCE_XXX to constexpr in the dylib

Since we build the dylib with C++20, there's no need to use conditional
macros anymore.

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

show more ...

[libc++] Remove symbols for a std::allocator_arg & friends from the dylib

This patch removes the symbols defined in the library for std::allocator_arg,
std::defer_lock, std::try_to_lock, std::adopt_

[libc++] Remove symbols for a std::allocator_arg & friends from the dylib

This patch removes the symbols defined in the library for std::allocator_arg,
std::defer_lock, std::try_to_lock, std::adopt_lock, and std::piecewise_construct.
Those were defined in the library because we provided them in C++03 as an
extension, and in C++03 it was impossible to define them as `constexpr`
variables, like in the spec.

This is technically an ABI break since we are removing symbols from the
library. However, in practice, only programs compiled in C++03 mode who
take the address of those objects (or pass them as a reference) will have
an undefined ref to those symbols. In practice, this is expected to be
rare. First, those are C++11 features that we happen to provide in C++03,
and only the C++03 definition can potentially lead to code referencing
the dylib definition. So any code that is using these objects but compiling
in C++11 mode (as they should) is not at risk. Second, all uses of these
types in the library is done by passing those types by value to a function
that can get inlined. Since they are empty types, the compiler won't
generate an undefined reference if passed by value, since there's nothing
to pass anyway.

Long story short, the risk for code actually containing an undefined
reference to one of these types is rather small (but non-zero). I also
couldn't find any app on the App Store that referenced these symbols,
which supports my impression that this won't be an issue in practice.

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

show more ...

[libc++] Avoid relying on non-portable behaviour in std::align

Round-tripping pointers via size_t is not portable, the C/C++ standards
only require this to be valid when using (u)intptr_t.
Originall

[libc++] Avoid relying on non-portable behaviour in std::align

Round-tripping pointers via size_t is not portable, the C/C++ standards
only require this to be valid when using (u)intptr_t.
Originally committed to the CHERI fork of LLVM as
https://github.com/CTSRD-CHERI/llvm-project/commit/dd01245185ab9e71b70b418bee8f11ea0199e1a3,
but I forgot to upstream the change. I rediscovered this issue due to a
compiler warning when building libc++ on a Arm Morello system.

Reviewed By: #libc, ldionne, philnik

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

show more ...

[libc++] Make the naming of private member variables consistent and enforce it through readability-identifier-naming

Reviewed By: ldionne, #libc

Spies: aheejin, sstefan1, libcxx-commits

Differenti

[libc++] Make the naming of private member variables consistent and enforce it through readability-identifier-naming

Reviewed By: ldionne, #libc

Spies: aheejin, sstefan1, libcxx-commits

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

show more ...

[libc++] Do not yield from __sp_mut::lock()

Instead of trying to be clever and design our own locking primitive,
simply rely on the OS-provided implementation to do the right thing.

Indeed, manuall

[libc++] Do not yield from __sp_mut::lock()

Instead of trying to be clever and design our own locking primitive,
simply rely on the OS-provided implementation to do the right thing.

Indeed, manually yielding to the OS does not provide the necessary
information for it to make good prioritization decisions. For example,
if a thread with higher priority yields while waiting for a lock held
by a thread with lower priority but the system is contended, it is
possible for the thread with lower priority to not run until the higher
priority thread has yielded 16 times and goes for __libcpp_mutex_lock().
Once that happens, the OS can bump the priority of the thread that
currently holds the lock to unblock everyone. So instead, we might as
well give the system all the information from the start so it can make
appropriate decisions.

As a fly-by change, also increase the number of locks in the table.
The size increase is modest, but has the potential to half the amount
of contention on those locks.

rdar://93598606

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

show more ...

[libc++][NFC] Fix whitespace

[libc++] Define legacy symbols for inline functions at a finer-grained level

When we build the library with the stable ABI, we need to include some
functions in the dylib that were made inline in la

[libc++] Define legacy symbols for inline functions at a finer-grained level

When we build the library with the stable ABI, we need to include some
functions in the dylib that were made inline in later versions of the
library (to avoid breaking code that might be relying on those symbols).

However, those methods were made non-inline whenever we'd be building
the library, which means that all translation units would end up using
the old out-of-line definition of these methods, as opposed to the new
inlined version. This patch makes it so that only the translation units
that actually define the out-of-line methods use the old definition,
opening up potential optimization opportunities in other translation
units.

This should solve some of the issues encountered in D65667.

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

show more ...

[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.

Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/inclu

[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.

Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/include/.

I've left `#include "include/x.h"` and `#include "../y.h"` alone
because I'm less sure that they're interchangeable, and they aren't
inconsistent with libcxx/include/ because libcxx/include/ never
does that kind of thing.

Also, use the `_LIBCPP_PUSH_MACROS/POP_MACROS` dance for `<__undef_macros>`,
even though it's technically unnecessary in a standalone .cpp file,
just so we have consistently one way to do it.

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

show more ...

[libc++] Rename *SAFE_STATIC to *CONSTINIT, and normalize its uses.

In src/, most files can use `constinit` directly because they're always
compiled with C++20. But some files, like "libcxxabi/src/f

[libc++] Rename *SAFE_STATIC to *CONSTINIT, and normalize its uses.

In src/, most files can use `constinit` directly because they're always
compiled with C++20. But some files, like "libcxxabi/src/fallback_malloc.cpp",
can't, because they're `#include`d directly from test cases in libcxxabi/test/
and therefore must (currently) compile as C++03. We might consider refactoring
those offending tests, or at least marking them `UNSUPPORTED: c++03`.

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

show more ...

[libc++] Enable <atomic> when threads are disabled

std::atomic is, for the most part, just a thin veneer on top of compiler
builtins. Hence, it should be available even when threads are not availabl

[libc++] Enable <atomic> when threads are disabled

std::atomic is, for the most part, just a thin veneer on top of compiler
builtins. Hence, it should be available even when threads are not available
on the system, and in fact there has been requests for such support.

This patch:
- Moves __libcpp_thread_poll_with_backoff to its own header so it can
be used in <atomic> when threads are disabled.
- Adds a dummy backoff policy for atomic polling that doesn't know about
threads.
- Adjusts the <atomic> feature-test macros so they are provided even when
threads are disabled.
- Runs the <atomic> tests when threads are disabled.

rdar://77873569

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

show more ...

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste st

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.

show more ...

[libc++] Implement P2186R2 (Remove Garbage Collection)

Reviewed By: Quuxplusone, #libc, ldionne

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

[libc++] Disentangle std::pointer_safety

This patch gets rid of technical debt around std::pointer_safety which,
I claim, is entirely unnecessary. I don't think anybody has used
std::pointer_safety

[libc++] Disentangle std::pointer_safety

This patch gets rid of technical debt around std::pointer_safety which,
I claim, is entirely unnecessary. I don't think anybody has used
std::pointer_safety in actual code because we do not implement the
underlying garbage collection support. In fact, P2186 even proposes
removing these facilities entirely from a future C++ version. As such,
I think it's entirely fine to get rid of complex workarounds whose goals
were to avoid breaking the ABI back in 2017.

I'm putting this up both to get reviews and to discuss this proposal for
a breaking change. I think we should be comfortable with making these
tiny breaks if we are confident they won't hurt anyone, which I'm fairly
confident is the case here.

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

show more ...

[libc++/abi] Replace uses of _NOEXCEPT in src/ by noexcept

We always build the libraries in a Standard mode that supports noexcept,
so there's no need to use the _NOEXCEPT macro.

Differential Revis

[libc++/abi] Replace uses of _NOEXCEPT in src/ by noexcept

We always build the libraries in a Standard mode that supports noexcept,
so there's no need to use the _NOEXCEPT macro.

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

show more ...

[libc++] Make __shared_weak_count vtable consistent across all build configurations

This patch ensures that __shared_weak_count provides a consistent vtable
regardless of if RTTI is enabled or if we

[libc++] Make __shared_weak_count vtable consistent across all build configurations

This patch ensures that __shared_weak_count provides a consistent vtable
regardless of if RTTI is enabled or if we are targeting a static or shared
libc++ build.

This patch is technically ABI breaking, but only for a very specific
configuration that no vendor should be shipping.

Note that _LIBCPP_BUILD_STATIC is not normally defined when building
libc++.a, but instead it must be manually provided by the user or the
__config_site.

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

show more ...

[libcxx{,abi}] Emit deplibs only when detected by CMake

This is a followup to 35bc5276ca3. It fixes the dependent libs usage
in libcxx and libcxxabi to link pthread and rt libraries only if CMake
d

[libcxx{,abi}] Emit deplibs only when detected by CMake

This is a followup to 35bc5276ca3. It fixes the dependent libs usage
in libcxx and libcxxabi to link pthread and rt libraries only if CMake
detects them, rather than based on explicit platform blacklist.

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

show more ...

[runtimes] Don't depend on libpthread on Android

r362048 added support for ELF dependent libraries, but broke Android
build since Android does not have libpthread. Remove the dependency on
the Andro

[runtimes] Don't depend on libpthread on Android

r362048 added support for ELF dependent libraries, but broke Android
build since Android does not have libpthread. Remove the dependency on
the Android build.

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

llvm-svn: 366734

show more ...

[runtimes] Use _LIBCPP_HAS_COMMENT_LIB_PRAGMA in all relevant files

These two sources were omitted in r362055.

llvm-svn: 362061

[runtimes] Support ELF dependent libraries feature

As of r360984, LLD supports dependent libraries feature for ELF.
libunwind, libc++abi and libc++ have library dependencies: libdl librt
and libpthr

[runtimes] Support ELF dependent libraries feature

As of r360984, LLD supports dependent libraries feature for ELF.
libunwind, libc++abi and libc++ have library dependencies: libdl librt
and libpthread, which means that when libunwind and libc++ are being
statically linked (using -static-libstdc++ flag), user has to manually
specify -ldl -lpthread which is onerous.

This change includes the lib pragma to specify the library dependencies
directly in the source that uses those libraries. This doesn't make any
difference when using linkers that don't support dependent libraries.
However, when using LLD that has dependent libraries feature, users no
longer have to manually specifying library dependencies when using
static linking, linker will pick the library automatically.

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

llvm-svn: 362048

show more ...

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351648

show more ...

[libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since _LIBCPP_BUILDING_LIBRARY

Summary: As suggested by Marshall in https://reviews.llvm.org/D49914

Reviewers: mclow.lists, EricWF

[libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since _LIBCPP_BUILDING_LIBRARY

Summary: As suggested by Marshall in https://reviews.llvm.org/D49914

Reviewers: mclow.lists, EricWF

Subscribers: christof, dexonsmith, cfe-commits

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

llvm-svn: 338475

show more ...

Fix incorrect usage of __libcpp_mutex_trylock. Patch from Andrey Khalyavin

llvm-svn: 302129

Use nullptr instead of the literal 0

llvm-svn: 302100