[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++] Handle threads-related .cpp files like we do all other source files (#71100)

Source files in libc++ are added to the CMake targets only if they are
required by the configuration. We do thi

[libc++] Handle threads-related .cpp files like we do all other source files (#71100)

Source files in libc++ are added to the CMake targets only if they are
required by the configuration. We do this pretty consistently for all
configurations like no-filesystem, no-random-device, etc. but we didn't
do it for no-threads. This patch makes this consistent for no-threads,
which is helpful in reducing the amount of work required to port libc++
to some platforms without threads.

Indeed, with the previous approach, several threads-related source files
would end up including headers that might fail to compile properly on
some platforms. This issue is sidestepped entirely by making the
approach for no-threads consistent with the other configurations.

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

Reviewed By: #libc, philnik

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

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

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

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

Make ~mutex and ~condition_variable trivial on Windows.

The implementations of __libcpp_mutex_destroy and __libcpp_condvar_destroy
are already NOPs, so this optimization is safe to perform.

See r36

Make ~mutex and ~condition_variable trivial on Windows.

The implementations of __libcpp_mutex_destroy and __libcpp_condvar_destroy
are already NOPs, so this optimization is safe to perform.

See r365273 and PR27658 for more information.

llvm-svn: 365281

show more ...

[libc++] Avoid using timespec when it might not be available

Summary:
The type timespec is unconditionally used in __threading_support.
Since the C library is only required to provide it in C11, thi

[libc++] Avoid using timespec when it might not be available

Summary:
The type timespec is unconditionally used in __threading_support.
Since the C library is only required to provide it in C11, this might
cause problems for platforms with external thread porting layer (i.e.
when _LIBCPP_HAS_THREAD_API_EXTERNAL is defined) with pre-C11
C libraries.

In our downstream port of libc++ we used to provide a definition of
timespec in __external_threading, but this solution is not ideal
because timespec is not a reserved name.

This patch renames timespec into __libcpp_timespec_t in the
thread-related parts of libc++. For all cases except external
threading this type is an alias for ::timespec (and no functional
changes are intended).

In case of external threading it is expected that the
__external_threading header will either provide a similar typedef (if
timespec is available in the vendor's C library) or provide a
definition of __libcpp_timespec_t compatible with POSIX timespec.

Reviewers: ldionne, mclow.lists, EricWF

Reviewed By: ldionne

Subscribers: dexonsmith, libcxx-commits, christof, carwil

Tags: #libc

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

llvm-svn: 364012

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++] Use #pragma push_macro/pop_macro to better handle min/max on Windows

Summary:
This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them an

[Libc++] Use #pragma push_macro/pop_macro to better handle min/max on Windows

Summary:
This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning.
This patch changes libc++ to use `#pragma push_macro` to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header.

Reviewers: mclow.lists, bcraig, compnerd, EricWF

Reviewed By: EricWF

Subscribers: cfe-commits, krytarowski

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

llvm-svn: 304357

show more ...

Recommit [libcxx] Never use <cassert> within libc++

It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`.
This patch remove all uses of `assert` from within libc++ and

Recommit [libcxx] Never use <cassert> within libc++

It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`.
This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead.

Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default,
because the standard library should not be aborting user programs unless explicitly asked to.

llvm-svn: 294107

show more ...

Revert "[libcxx] Never use <cassert> within libc++"

This reverts commit r292883. Unfortunately <string_view> uses
_LIBCPP_ASSERT in a way which is not compatible with the C++11 dylib
build. I'll inv

Revert "[libcxx] Never use <cassert> within libc++"

This reverts commit r292883. Unfortunately <string_view> uses
_LIBCPP_ASSERT in a way which is not compatible with the C++11 dylib
build. I'll investigate more tomorrow.

llvm-svn: 292923

show more ...

[libcxx] Never use <cassert> within libc++

Summary:
It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`. This patch remove all uses of `assert` from within libc++ and

[libcxx] Never use <cassert> within libc++

Summary:
It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`. This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead.

Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default, because the standard library should not be aborting user programs unless explicitly asked to.

Reviewers: mclow.lists, compnerd, smeenai

Reviewed By: mclow.lists

Subscribers: mgorny, cfe-commits

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

llvm-svn: 292883

show more ...

Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread context.

Summary:
This patch allows threads not created using `std::thread` to use `std::notify_all_at_thread_exit` by en

Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread context.

Summary:
This patch allows threads not created using `std::thread` to use `std::notify_all_at_thread_exit` by ensuring the TL state has been initialized within `std::notify_all_at_thread_exit`.

Additionally this patch "fixes" a potential oddity in `__thread_local_pointer::reset(pointer)`, which would previously delete the old thread local data. However there should *never* be old thread local data because pthread *should* null it out on thread exit. Unfortunately it's possible that pthread failed to do this according to the spec:


>
> Upon key creation, the value NULL shall be associated with the new key in all active threads. Upon thread creation, the value NULL shall be associated with all defined keys in the new thread.
>
> An optional destructor function may be associated with each key value. At thread exit, if a key value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with that key, the value of the key is set to NULL, and then the function pointed to is called with the previously associated value as its sole argument. The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits.
>
> If, after all the destructors have been called for all non-NULL values with associated destructors, there are still some non-NULL values with associated destructors, then the process is repeated. If, after at least {PTHREAD_DESTRUCTOR_ITERATIONS} iterations of destructor calls for outstanding non-NULL values, there are still some non-NULL values with associated destructors, implementations may stop calling destructors, or they may continue calling destructors until no non-NULL values with associated destructors exist, even though this might result in an infinite loop.

However if pthread fails to delete the value it is probably incorrect for us to do it. Destroying the value performs all of the "at thread exit" actions registered with it but we are way past "at thread exit".





Reviewers: mclow.lists, bcraig, EricWF

Subscribers: cfe-commits

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

llvm-svn: 280588

show more ...

Refactor pthread usage of libcxx.

This patch extracts out all the pthread dependencies of libcxx into the
new header __threading_support. The motivation is to make it easy to
re-target libcxx into p

Refactor pthread usage of libcxx.

This patch extracts out all the pthread dependencies of libcxx into the
new header __threading_support. The motivation is to make it easy to
re-target libcxx into platforms that do not support pthread.

Original patch from Fulvio Esposito (fulvio.esposito@outlook.com) - D11781

Applied with tweaks - D19412

Change-Id: I301111f0075de93dd8129416e06babc195aa936b
llvm-svn: 268734

show more ...

Allow libc++ to be built on systems without POSIX threads

If you're crazy enough to want this sort of thing, then add
-D_LIBCPP_HAS_NO_THREADS to your CXXFLAGS and
--param=additiona_features=libcpp-

Allow libc++ to be built on systems without POSIX threads

If you're crazy enough to want this sort of thing, then add
-D_LIBCPP_HAS_NO_THREADS to your CXXFLAGS and
--param=additiona_features=libcpp-has-no-threads to your lit commnad line.

http://reviews.llvm.org/D3969

llvm-svn: 217271

show more ...

Implement LWG issue #2135. If something goes wrong in condition_variable::wait, call terminate() rather than throwing an error. Do this indirectly, by marking the call as 'noexcept'. This is better t

Implement LWG issue #2135. If something goes wrong in condition_variable::wait, call terminate() rather than throwing an error. Do this indirectly, by marking the call as 'noexcept'. This is better than just calling terminate() directly, because it gives a better error message on the console.

llvm-svn: 204778

show more ...

Change sleep_for, sleep_until, and the condition_variable timed wait
functions to protect against duration and time_point overflow. Since
we're about to wait anyway, we can afford to spend a few mor

Change sleep_for, sleep_until, and the condition_variable timed wait
functions to protect against duration and time_point overflow. Since
we're about to wait anyway, we can afford to spend a few more cycles on
this checking. I purposefully did not treat the timed try_locks with
overflow checking. This fixes
http://llvm.org/bugs/show_bug.cgi?id=13721 . I'm unsure if the standard
needs clarification in this area, or if this is simply QOI. The
<chrono> facilities were never intended to overflow check, but just to
not overflow if durations stayed within +/- 292 years.

llvm-svn: 162925

show more ...

noexcept applied to <condition_variable>.

llvm-svn: 160605

Quash a whole bunch of warnings

llvm-svn: 145624