[libc++][RFC] Always define internal feature test macros (#89178)

Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`

[libc++][RFC] Always define internal feature test macros (#89178)

Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`_LIBCPP_HAS_NO_`. This patch changes that, so that they are always
defined and have the prefix `_LIBCPP_HAS_` instead. This changes the
canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means
that using an undefined macro (e.g. due to a missing include) is
diagnosed now. While this is rather unlikely currently, a similar change
in `<__configuration/availability.h>` caught a few bugs. This also
improves readability, since it removes the double-negation of `#ifndef
_LIBCPP_HAS_NO_FEATURE`.

The current patch only touches the macros defined in `<__config>`. If
people are happy with this approach, I'll make a follow-up PR to also
change the macros defined in `<__config_site>`.

show more ...

[libc++abi] Revert temporary workaround to unblock Chrome

This reverts commit 372f7dd48f016, which is not needed by Chrome anymore.

[libc++abi] Add temporary workaround to unblock Chrome

Chrome rolls libc++ and libc++abi as separate projects. As a result, they
may not always be updated in lockstep, and this can lead to build fai

[libc++abi] Add temporary workaround to unblock Chrome

Chrome rolls libc++ and libc++abi as separate projects. As a result, they
may not always be updated in lockstep, and this can lead to build failures
when mixing libc++ that doesn't have <__thread/support.h> with libc++abi
that requires it.

This patch adds a workaround to make libc++abi work with both versions.
While Chrome's setup is not supported, this workaround will allow them
to go back to green and do the required work needed to roll libc++ and
libc++abi in lockstep. This workaround will be short-lived -- I have a
reminder to go back and remove it by EOW.

show more ...

[libc++] Split the monolithic __threading_support header (#79654)

The <__threading_support> header is a huge beast and it's really
difficult to navigate. I find myself struggling to find what I wan

[libc++] Split the monolithic __threading_support header (#79654)

The <__threading_support> header is a huge beast and it's really
difficult to navigate. I find myself struggling to find what I want
every time I have to open it, and I've been considering splitting it up
for years for that reason.

This patch aims not to contain any functional change. The various
implementations of the threading base are simply moved to separate
headers and then the individual headers are simplified in mechanical
ways. For example, we used to have redundant declarations of all the
functions at the top of `__threading_support`, and those are removed
since they are not needed anymore. The various #ifdefs are also
simplified and removed when they become unnecessary.

Finally, this patch adds documentation for the API we expect from any
threading implementation.

show more ...

[libc++abi] Avoid raw calls to assert() in libc++abi (#71121)

The runtimes now have a principled way of doing assertions in relation
to hardening, so we should use that instead of raw calls to asse

[libc++abi] Avoid raw calls to assert() in libc++abi (#71121)

The runtimes now have a principled way of doing assertions in relation
to hardening, so we should use that instead of raw calls to assert()
inside libc++abi. This patch aims to maintain the behavior of the
demangler code when it is used from within LLVM by introducing a simple
DEMANGLE_ASSERT(...) macro that is then defined to the appropriate
assertion mechanism.

show more ...

[libc++] Move the definition of aligned allocation helpers outside of <new>

They are not needed in <new> -- in fact they are only needed in .cpp files.
Getting those out of the way makes the headers

[libc++] Move the definition of aligned allocation helpers outside of <new>

They are not needed in <new> -- in fact they are only needed in .cpp files.
Getting those out of the way makes the headers smaller and also makes it
easier to use the library on platforms where aligned allocation is not
available.

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

show more ...

Revert "[libcxxabi] Always use thread_local for cxa_exception_storage"

This reverts commit 8271aa5335668a1dc62168a4e90b4554bd3a0ca7 since it
broke some downstream builds. See https://reviews.llvm.or

Revert "[libcxxabi] Always use thread_local for cxa_exception_storage"

This reverts commit 8271aa5335668a1dc62168a4e90b4554bd3a0ca7 since it
broke some downstream builds. See https://reviews.llvm.org/D138461 for
details.

show more ...

[libcxxabi] Always use thread_local for cxa_exception_storage

This was previously guarded by HAS_THREAD_LOCAL, which was never set by
CMake and had to be specified manually. Android has been setting

[libcxxabi] Always use thread_local for cxa_exception_storage

This was previously guarded by HAS_THREAD_LOCAL, which was never set by
CMake and had to be specified manually. Android has been setting this to
solve https://github.com/android/ndk/issues/1200 [1], but every compiler
and platform libc++abi supports should have thread_local by now, so we
can just get rid of the fallback implementation and simplify things
significantly (including removing the now unused fallback calloc).

[1] https://android-review.googlesource.com/c/toolchain/llvm-project/+/1285596

Reviewed By: #libc_abi, MaskRay, ldionne

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

show more ...

[libcxxabi] Fix alignment of pointers returned by fallback_malloc

This aligns the ``heap[]`` array in ``fallback_malloc.cpp`` to ensure
that it can be safely cast to ``heap_node*``, and also adjusts

[libcxxabi] Fix alignment of pointers returned by fallback_malloc

This aligns the ``heap[]`` array in ``fallback_malloc.cpp`` to ensure
that it can be safely cast to ``heap_node*``, and also adjusts the
allocation algorithm to ensure that every allocated block has the
alignment requested by ``__attribute__((aligned))``, by putting the
block's ``heap_node`` header 4 bytes before an aligned address.

Patch originally by Eric Fiselier: this is an updated version of
D12669, which was never landed.

Reviewed By: ldionne, #libc_abi

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

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++] 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 ...

[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++abi] Don't try calling __libcpp_aligned_free when aligned allocation is disabled

See https://reviews.llvm.org/rGa78aaa1ad512#962077 for details.

[libc++] Factor out common logic for calling aligned allocation

There were a couple of places where we needed to call the underlying
platform's aligned allocation/deallocation function. Instead of h

[libc++] Factor out common logic for calling aligned allocation

There were a couple of places where we needed to call the underlying
platform's aligned allocation/deallocation function. Instead of having
the same logic all over the place, extract the logic into a pair of
helper functions __libcpp_aligned_alloc and __libcpp_aligned_free.

The code in libcxxabi/src/fallback_malloc.cpp looks like it could be
simplified after this change -- I purposefully did not simplify it
further to keep this change as straightforward as possible, since it
is touching very important parts of the library.

Also, the changes in libcxx/src/new.cpp and libcxxabi/src/stdlib_new_delete.cpp
are basically the same -- I just kept both source files in sync.

The underlying reason for this refactoring is to make it easier to support
platforms that provide aligned allocation through C11's aligned_alloc
function instead of posix_memalign. After this change, we'll only have
to add support for that in a single place.

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

show more ...

[libcxxabi] Build all of libcxxabi with _LIBCPP_BUILDING_LIBRARY defined

Various definitions from libcxx need to be set in the same way
as if building libcxx itself.

Differential Revision: https://

[libcxxabi] Build all of libcxxabi with _LIBCPP_BUILDING_LIBRARY defined

Various definitions from libcxx need to be set in the same way
as if building libcxx itself.

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

show more ...

[libc++/abi] Clean up uses of <iostream> in the test suite

We used <iostream> in several places where we don't actually need the
full power of <iostream>, and where using basic `std::printf` is enou

[libc++/abi] Clean up uses of <iostream> in the test suite

We used <iostream> in several places where we don't actually need the
full power of <iostream>, and where using basic `std::printf` is enough.
This is better, since `std::printf` can be supported on systems that don't
have a notion of locales, while <iostream> can't.

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

[libc++abi] Remove uses of C++ headers when possible

This reduces the (circular) dependency of libc++abi on a C++ standard
library. Outside of the demangler which uses fancier C++ features, the
only

[libc++abi] Remove uses of C++ headers when possible

This reduces the (circular) dependency of libc++abi on a C++ standard
library. Outside of the demangler which uses fancier C++ features, the
only C++ headers now required by libc++abi are pretty much <new> and
<exception>, and that's because libc++abi defines some types that are
declared in those headers.

llvm-svn: 373381

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] Check if pragma comment(lib, ...) is supported first

This fixes the issue introduced by r362048 where we always use
pragma comment(lib, ...) for dependent libraries when the compiler
is C

[runtimes] Check if pragma comment(lib, ...) is supported first

This fixes the issue introduced by r362048 where we always use
pragma comment(lib, ...) for dependent libraries when the compiler
is Clang, but older Clang versions don't support this pragma so
we need to check first if it's supported before using it.

llvm-svn: 362055

show more ...

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

Use C++03 friendly version of alignof

llvm-svn: 344215

Update libc++abi's detection of aligned allocation after r344207.

llvm-svn: 344208