[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++][NFC] Granularise <thread> header

- This was to make implementing jthread easier and requested in https://reviews.llvm.org/D151559

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

[libc++] Hold mutex lock while notify_all is called at notify_all_at_thread_exit

Releasing the mutex before the call to notify_all is an optimization.
This optimization cannot be used here. The thre

[libc++] Hold mutex lock while notify_all is called at notify_all_at_thread_exit

Releasing the mutex before the call to notify_all is an optimization.
This optimization cannot be used here. The thread waiting on the
condition might destroy the associated resources — mutex + condition
variable — and the notifier thread will access an destroyed variable
— the condition variable. In fact, notify_all_at_thread_exit is meant
exactly to join on detached threads, and the waiting thread doesn't
expect for the notifier thread to access any further shared resources,
making this scenario very likely to happen. The waiting thread might
awake spuriously on the release of the mutex lock. The reorder is
necessary to prevent this race.

Further details can be found at https://cplusplus.github.io/LWG/issue3343.

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

show more ...

[libc++] Avoid lifetime UB in __thread_local_data()

Detected on many lld tests with -fsanitize-memory-use-after-dtor.
Also https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-fast after

[libc++] Avoid lifetime UB in __thread_local_data()

Detected on many lld tests with -fsanitize-memory-use-after-dtor.
Also https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-fast after D122869 will report a lot of them.

Threads may outlive static variables. Even if ~__thread_specific_ptr() does nothing, lifetime of members ends with ~ and accessing the value is UB https://eel.is/c++draft/basic.life#1

```
==9214==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x557e1cec4539 in __libcpp_tls_set ../include/c++/v1/__threading_support:428:12
#1 0x557e1cec4539 in set_pointer ../include/c++/v1/thread:196:5
#2 0x557e1cec4539 in void* std::__msan::__thread_proxy<
std::__msan::tuple<...>, llvm::parallel::detail::(anonymous namespace)::ThreadPoolExecutor::ThreadPoolExecutor(llvm::ThreadPoolStrategy)::'lambda'()::operator()() const::'lambda'()> >(void*) ../include/c++/v1/thread:285:27

Memory was marked as uninitialized
#0 0x557e10a0759d in __sanitizer_dtor_callback compiler-rt/lib/msan/msan_interceptors.cpp:940:5
#1 0x557e1d8c478d in std::__msan::__thread_specific_ptr<std::__msan::__thread_struct>::~__thread_specific_ptr() libcxx/include/thread:188:1
#2 0x557e10a07dc0 in MSanCxaAtExitWrapper(void*) compiler-rt/lib/msan/msan_interceptors.cpp:1151:3
```

The test needs D123979 or -fsanitize-memory-param-retval enabled by default.

Reviewed By: ldionne, #libc

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

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++] NFC: Normalize `#endif //` comment indentation

[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++] Remove sysctl-based implementation of thread::hardware_concurrency()

Using sysctl requires including headers that are considered internal on
Linux, like <sys/sysctl.h> & friends. Instead, s

[libc++] Remove sysctl-based implementation of thread::hardware_concurrency()

Using sysctl requires including headers that are considered internal on
Linux, like <sys/sysctl.h> & friends. Instead, sysconf is defined by POSIX
(and we have a fallback for Windows), so all the systems we support should
be happy with just sysconf.

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

show more ...

[libc++] Use __has_include instead of complex logic in thread.cpp

We might end up including more headers than strictly necessary this way,
but it's much simpler and it makes it easier to port thread

[libc++] Use __has_include instead of complex logic in thread.cpp

We might end up including more headers than strictly necessary this way,
but it's much simpler and it makes it easier to port thread.cpp to systems
not handled by the existing conditionals.

show more ...

[libc++] Adjust how we guard the inclusion of unistd.h

unistd.h isn't guaranteed to exist when the target isn't Windows, in
particular if the target is bare-metal (i.e. no operating system).
Handle

[libc++] Adjust how we guard the inclusion of unistd.h

unistd.h isn't guaranteed to exist when the target isn't Windows, in
particular if the target is bare-metal (i.e. no operating system).
Handle this by using __has_include instead, though in
filesystem/operations.cpp we already unconditionally include it so
just remove the extra include.

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

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

[libcxx][NFC] Strip trailing whitespace, fix typo.

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

[WebAssembly] WASI support for libcxx

This adds explicit support for the WASI platform to libcxx.

WASI libc uses some components from musl, however it's not fully compatible
with musl, so we're pla

[WebAssembly] WASI support for libcxx

This adds explicit support for the WASI platform to libcxx.

WASI libc uses some components from musl, however it's not fully compatible
with musl, so we're planning to stop using _LIBCPP_HAS_MUSL_LIBC and
customize for WASI libc specifically.

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

Reviewers: sbc100, ldionne
llvm-svn: 359703

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

[libcxx] GNU/Hurd uses BSD-based interfaces, but does not (and won't) provide <sys/sysctl.h>

Reviewed as https://reviews.llvm.org/D54338.

Thanks to sthibaul for the patch.

llvm-svn: 346763

Fix Libc++ build with MinGW64

Summary: This patch corrects the build errors I encountered when building on MinGW64.

Reviewers: mati865, rnk, compnerd, smeenai, bcraig

Reviewed By: mati865, smeenai

Fix Libc++ build with MinGW64

Summary: This patch corrects the build errors I encountered when building on MinGW64.

Reviewers: mati865, rnk, compnerd, smeenai, bcraig

Reviewed By: mati865, smeenai

Subscribers: martell, chapuni, cfe-commits

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

llvm-svn: 304360

show more ...

Remove usages of _LIBCPP_MSVC which is never defined

llvm-svn: 302736

[libcxx] Support threads on Fuchsia

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

llvm-svn: 296573

Fix the build of thread.cpp on CloudABI.

CloudABI does provide unistd.h, but doesn't define __unix__. We need to
include this header file to make hardware_concurrency work.

llvm-svn: 294832

Threading support: externalize sleep_for() function.

Different platforms implement the wait/sleep functions in difrerent ways.
It makes sense to externalize this into the threading API.

Differentia

Threading support: externalize sleep_for() function.

Different platforms implement the wait/sleep functions in difrerent ways.
It makes sense to externalize this into the threading API.

Differential revision: https://reviews.llvm.org/D29630

Reviewers: EricWF, joerg
llvm-svn: 294573

show more ...

Refer to _LIBCPP_MSVC macro where applicable

Replace preprocess conditions of defined(_MSC_VER) &&
!defined(__clang__) with defined(_LIBCPP_MSVC). NFC.

Patch by Dave Lee!

llvm-svn: 294171