[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional change: it simply moves
_LIBCPP_ASSERT-related stuff to its own file so as to make it clear that
libc++ assertions and the debug mode are different things. Future patches
will make it possible to enable assertions without enabling the debug
mode.

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

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

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

[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++] Take 2: Implement LWG 2510

Summary:
LWG2510 makes tag types like allocator_arg_t explicitly default
constructible instead of implicitly default constructible. It also
makes the constructors

[libc++] Take 2: Implement LWG 2510

Summary:
LWG2510 makes tag types like allocator_arg_t explicitly default
constructible instead of implicitly default constructible. It also
makes the constructors for std::pair and std::tuple conditionally
explicit based on the explicit-ness of the default constructibility
for the pair/tuple's elements.

This was previously committed as r372777 and reverted in r372832 due to
the commit breaking LLVM's build in C++14 mode. This issue has now been
addressed.

Reviewers: mclow.lists

Subscribers: christof, jkorous, dexonsmith, libcxx-commits

Tags: #libc

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

llvm-svn: 372983

show more ...

Revert r372777: [libc++] Implement LWG 2510 and its follow-ups

This also reverts:
- r372778: [libc++] Implement LWG 3158
- r372782: [libc++] Try fixing tests that fail on GCC 5 and older
- r37278

Revert r372777: [libc++] Implement LWG 2510 and its follow-ups

This also reverts:
- r372778: [libc++] Implement LWG 3158
- r372782: [libc++] Try fixing tests that fail on GCC 5 and older
- r372787: Purge mentions of GCC 4 from the test suite

Reason: the change breaks compilation of LLVM with libc++, for details see
http://lists.llvm.org/pipermail/libcxx-dev/2019-September/000599.html

llvm-svn: 372832

show more ...

[libc++] Implement LWG 2510

Summary:
LWG2510 makes tag types like allocator_arg_t explicitly default
constructible instead of implicitly default constructible. It also
makes the constructors for std

[libc++] Implement LWG 2510

Summary:
LWG2510 makes tag types like allocator_arg_t explicitly default
constructible instead of implicitly default constructible. It also
makes the constructors for std::pair and std::tuple conditionally
explicit based on the explicit-ness of the default constructibility
for the pair/tuple's elements.

Reviewers: mclow.lists, EricWF

Subscribers: christof, jkorous, dexonsmith, libcxx-commits

Tags: #libc

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

llvm-svn: 372777

show more ...

Fix thread comparison by making sure we never pass our special 'not a thread' value to the underlying implementation. Fixes PR#42918.

llvm-svn: 368916

Rework recursive_timed_mutex so that it uses __thread_id instead of using the lower-level __libcpp_thread_id. This is prep for fixing PR42918. Reviewed as https://reviews.llvm.org/D65895

llvm-svn: 3

Rework recursive_timed_mutex so that it uses __thread_id instead of using the lower-level __libcpp_thread_id. This is prep for fixing PR42918. Reviewed as https://reviews.llvm.org/D65895

llvm-svn: 368867

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

Fix PR27658 - Make ~mutex trivial when possible.

Currently std::mutex has a constexpr constructor, but a non-trivial
destruction.

The constexpr constructor is required to ensure the construction of

Fix PR27658 - Make ~mutex trivial when possible.

Currently std::mutex has a constexpr constructor, but a non-trivial
destruction.

The constexpr constructor is required to ensure the construction of a
mutex with static storage duration happens at compile time, during
constant initialization, and not during dynamic initialization.
This means that static mutex's are always initialized and can be used
safely during dynamic initialization without the "static initialization
order fiasco".

A trivial destructor is important for similar reasons. If a mutex is
used during dynamic initialization it might also be used during program
termination. If a static mutex has a non-trivial destructor it will be
invoked during termination. This can introduce the "static
deinitialization order fiasco".

Additionally, function-local statics emit a guard variable around
non-trivially destructible types. This results in horrible codegen and
adds a runtime cost to every call to that function. non-local static's
also result in slightly worse codegen but it's not as big of a problem.

Example codegen can be found here: https://goo.gl/3CSzbM

Note: This optimization is not safe with every pthread implementation.
Some implementations allocate on the first call to pthread_mutex_lock
and free the allocation in pthread_mutex_destroy.

Also, changing the triviality of the destructor is not an ABI break.
At least to the best of my knowledge :-)

llvm-svn: 365273

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

Fix r359229 which tried to fix r359159...

When r359229 added noexcept to the declaration of `~mutex`, it didn't
add it to the definition which caused -Wimplicit-exception-spec-mismatch
to fire. This

Fix r359229 which tried to fix r359159...

When r359229 added noexcept to the declaration of `~mutex`, it didn't
add it to the definition which caused -Wimplicit-exception-spec-mismatch
to fire. This just adapts the definition to agree with the declaration.

llvm-svn: 359275

show more ...

libc++/win: Make once_flag have the same size as a pointer.

`unsigned long` is 32-bit on 32-bit systems and 64-bit on 64-bit systems
on LP64 systems -- which most Unix systems are, but Windows isn't

libc++/win: Make once_flag have the same size as a pointer.

`unsigned long` is 32-bit on 32-bit systems and 64-bit on 64-bit systems
on LP64 systems -- which most Unix systems are, but Windows isn't.
Windows is LLP64, which means unsigned long is 32-bit even on 64-bit
systems.

pplwin.h contains

static_assert(alignof(void *) == alignof(::std::once_flag), ...)

which fails due to this problem.

Instead of unsigned long, use uintptr_t, which consistently is 32-bit
on 32-bit systems and 64-bit on 64-bit systems.

No functional change except on 64-bit Windows.

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

llvm-svn: 356624

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

[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 Windows try_lock implementation

llvm-svn: 292011