[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++] 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++] Make future_error constructor standard-compliant

This patch removes the non compliant constructor of std::future_error
and adds the standards compliant constructor in C++17 instead.

Note t

[libc++] Make future_error constructor standard-compliant

This patch removes the non compliant constructor of std::future_error
and adds the standards compliant constructor in C++17 instead.

Note that we can't support the constructor as an extension in all
standard modes because it uses delegating constructors, which require
C++11. We could in theory support the constructor as an extension in
C++11 and C++14 only, however I believe it is acceptable not to do that
since I expect the breakage from this patch will be minimal.

If it turns out that more code than we expect is broken by this, we can
reconsider that decision.

This was found during D99515.

Differential Revision: https://reviews.llvm.org/D99567
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>

show more ...

[libc++] Avoid destructor call for error_category singletons

When a handle to an error_category singleton object is used during the
termination phase of a program, the destruction of the error_categ

[libc++] Avoid destructor call for error_category singletons

When a handle to an error_category singleton object is used during the
termination phase of a program, the destruction of the error_category
object may have occurred prior to execution of the current destructor
or function registered with atexit, because the singleton object may
have been constructed after the corresponding initialization or call
to atexit. For example, the updated tests from this patch will fail if
using a libc++ built using a compiler that updates the vtable of the
object on destruction.

This patch attempts to avoid the issue by causing the destructor to not
be called in the style of ResourceInitHelper in src/experimental/memory_resource.cpp.
This approach might not work if object lifetime is strictly enforced.

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

Co-authored-by: Louis Dionne <ldionne.2@gmail.com>

show more ...

[libc++][NFC] Rename _LIBCPP_NO_EXCEPTIONS to _LIBCPP_HAS_NO_EXCEPTIONS

Other macros that disable parts of the library are named `_LIBCPP_HAS_NO_WHATEVER`.

Reviewed By: ldionne, Mordante, #libc

Sp

[libc++][NFC] Rename _LIBCPP_NO_EXCEPTIONS to _LIBCPP_HAS_NO_EXCEPTIONS

Other macros that disable parts of the library are named `_LIBCPP_HAS_NO_WHATEVER`.

Reviewed By: ldionne, Mordante, #libc

Spies: libcxx-commits, smeenai

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

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

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

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 race condition in std::async

Summary:
The state associated to the future was set in one thread (with synchronization)
but read in another thread without synchronization, which led to

[libc++] Remove race condition in std::async

Summary:
The state associated to the future was set in one thread (with synchronization)
but read in another thread without synchronization, which led to a data race.

https://bugs.llvm.org/show_bug.cgi?id=38181
rdar://problem/42548261

Reviewers: mclow.lists, EricWF

Subscribers: christof, dexonsmith, cfe-commits

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

llvm-svn: 340608

show more ...

Code cleanup - change naked 'throw' expressions to call helpre function '__throw_future_error'. The behavior change is that if you build libc++ with exceptions disabled, and then use that in a progra

Code cleanup - change naked 'throw' expressions to call helpre function '__throw_future_error'. The behavior change is that if you build libc++ with exceptions disabled, and then use that in a program that sets the value of the future twice (for example), it will now abort instead of behaving unpredictably.

llvm-svn: 338332

show more ...

Make it possible to build a no-exceptions variant of libcxx.

Fixes a small omission in libcxx that prevents libcxx being built when
-DLIBCXX_ENABLE_EXCEPTIONS=0 is specified.

This patch adds XFAILS

Make it possible to build a no-exceptions variant of libcxx.

Fixes a small omission in libcxx that prevents libcxx being built when
-DLIBCXX_ENABLE_EXCEPTIONS=0 is specified.

This patch adds XFAILS to all those tests that are currently failing
on the new -fno-exceptions library variant. Follow-up patches will
update the tests (progressively) to cope with the new library variant.

Change-Id: I4b801bd8d8e4fe7193df9e55f39f1f393a8ba81a
llvm-svn: 252598

show more ...

Fix PR23293 - Do not unlock shared state before notifying consumers.

Within the shared state methods do not unlock the lock guards manually. This
could cause a race condition where the shared state

Fix PR23293 - Do not unlock shared state before notifying consumers.

Within the shared state methods do not unlock the lock guards manually. This
could cause a race condition where the shared state is destroyed before the
method is complete.

llvm-svn: 239577

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

Fix GCC unknown pragma warning in libc++.

We should check defined(__clang__) before the usage of the
clang diagnostic pragmas.

The [-Wswitch] warning in src/future.cpp should be ignored.
As the res

Fix GCC unknown pragma warning in libc++.

We should check defined(__clang__) before the usage of the
clang diagnostic pragmas.

The [-Wswitch] warning in src/future.cpp should be ignored.
As the result, the equivalent GCC pragma is added.

llvm-svn: 197314

show more ...

Marshall Clow: LWG Issue 2056: future_errc enums start with value 0 (invalid value for broken_promise).

llvm-svn: 190756

Fix a race in the construction of future. This fixes http://llvm.org/bugs/show_bug.cgi?id=14934.

llvm-svn: 172456

noexcept applied to <future>.

llvm-svn: 160607

Explicitly convert int to future_errc. Fixes http://llvm.org/bugs/show_bug.cgi?id=11428

llvm-svn: 149630

Quash a whole bunch of warnings

llvm-svn: 145624

http://llvm.org/bugs/show_bug.cgi?id=10346

llvm-svn: 135045

provide ~future_error() definition

llvm-svn: 134663

noexcept for <memory>. I've added a few extension noexcept to: allocator_traits<A>::deallocate, allocaate<T>::deallocate, return_temporary_buffer, and default_delete<T>::operator()(T*) const. My r

noexcept for <memory>. I've added a few extension noexcept to: allocator_traits<A>::deallocate, allocaate<T>::deallocate, return_temporary_buffer, and default_delete<T>::operator()(T*) const. My rationale was: If a std-dicated noexcept function needs to call another std-defined function, that called function must be noexcept. We're all a little new to noexcept, so things like this are to be expected. Also included fix for broken __is_swappable trait pointed out by Marc Glisse, thanks Marc|. And fixed a test case for is_nothrow_destructible. Destructors are now noexcept by default|

llvm-svn: 132261

show more ...