[libc++][NFC] Replace enable_if with __enable_if_t in a few places

Reviewed By: ldionne, #libc

Spies: jloser, libcxx-commits

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

[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++] Granularize chrono includes

Reviewed By: Quuxplusone, #libc

Spies: libcxx-commits

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

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

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

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

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

show more ...

[libc++] Modularize <chrono>

I didn't split the calendar bits more than this because there was little
benefit to doing it, and I know our calendar support is incomplete.
Whoever picks up the missing

[libc++] Modularize <chrono>

I didn't split the calendar bits more than this because there was little
benefit to doing it, and I know our calendar support is incomplete.
Whoever picks up the missing calendar bits can organize these headers
at their leisure.

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

show more ...

[libc++] `= delete` member functions with // = delete;

Use `= delete` for member functions that are marked with `// = delete;`

Reviewed By: ldionne, Quuxplusone, #libc

Spies: jloser, libcxx-commit

[libc++] `= delete` member functions with // = delete;

Use `= delete` for member functions that are marked with `// = delete;`

Reviewed By: ldionne, Quuxplusone, #libc

Spies: jloser, libcxx-commits

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

show more ...

[libc++][NFCI] Remove uses of _LIBCPP_INLINE_VAR

All supported compilers provide support for inline variables in C++17 now.
Also, as a fly-by fix, replace some uses of _LIBCPP_CONSTEXPR by just
cons

[libc++][NFCI] Remove uses of _LIBCPP_INLINE_VAR

All supported compilers provide support for inline variables in C++17 now.
Also, as a fly-by fix, replace some uses of _LIBCPP_CONSTEXPR by just
constexpr.

The only exception in this patch is `std::ignore`, which is provided
prior to C++17. Since it is defined in an anonymous namespace, it always
has internal linkage anyway, so using an inline variable there doesn't
provide any benefit. Instead, `inline` was removed entirely on `std::ignore`.

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

show more ...

Eliminate _LIBCPP_EQUAL_DELETE in favor of `=delete`.

All supported compilers have supported `=delete` as an extension
in C++03 mode for many years at this point.

Differential Revision: https://rev

Eliminate _LIBCPP_EQUAL_DELETE in favor of `=delete`.

All supported compilers have supported `=delete` as an extension
in C++03 mode for many years at this point.

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

show more ...

[libc++] Enable `explicit` conversion operators, even in C++03 mode.

C++03 didn't support `explicit` conversion operators;
but Clang's C++03 mode does, as an extension, so we can use it.
This lets u

[libc++] Enable `explicit` conversion operators, even in C++03 mode.

C++03 didn't support `explicit` conversion operators;
but Clang's C++03 mode does, as an extension, so we can use it.
This lets us make the conversion explicit in `std::function` (even in '03),
and remove some silly metaprogramming in `std::basic_ios`.

Drive-by improvements to the tests for these operators, in addition
to making sure all these tests also run in `c++03` mode.

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

show more ...

[libc++] Alphabetize and include-what-you-use. NFCI.

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

[libc++] NFC: Normalize `#endif //` comment indentation

[libc++] ADL-proof vector<bool> by adding _VSTD:: qualification on calls.

This affects only vectors with weird/malicious allocators,
the same corner case covered in D91708, but for `vector<bool>` th

[libc++] ADL-proof vector<bool> by adding _VSTD:: qualification on calls.

This affects only vectors with weird/malicious allocators,
the same corner case covered in D91708, but for `vector<bool>` this time.

Also ADL-proof <__tree>, which affects only sets and maps with weird/malicious
allocators where the ADL trap is in the *fancy pointer type*.

Also drive-by _VSTD:: qualification in the guts of std::bind,
std::packaged_task, std::condition_variable.

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

show more ...

[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.

I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. T

[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.

I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:

- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.

- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.

- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.

In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.

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

show more ...

[libc++] Remove some workarounds for C++03

We don't support any compiler that doesn't support variadics and rvalue
references in C++03 mode, so these workarounds can be dropped. There's
still *a lot

[libc++] Remove some workarounds for C++03

We don't support any compiler that doesn't support variadics and rvalue
references in C++03 mode, so these workarounds can be dropped. There's
still *a lot* of cruft related to these workarounds, but I try to tackle
a bit of it here and there.

show more ...

[libc++] Ensure __config always defines certain configuration macros.

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

Revert "Revert "Implement std::condition_variable via pthread_cond_clockwait() where available""

With the fix for non-Linux.

This reverts commit c1c519d2f1a66dd2eeaa4c321d8d7b50f623eb71.

llvm-svn:

Revert "Revert "Implement std::condition_variable via pthread_cond_clockwait() where available""

With the fix for non-Linux.

This reverts commit c1c519d2f1a66dd2eeaa4c321d8d7b50f623eb71.

llvm-svn: 372242

show more ...

Revert "Implement std::condition_variable via pthread_cond_clockwait() where available"

This reverts commit 5e37d7f9ff257ec62d733d3d94b11f03e0fe51ca.

llvm-svn: 372034

Implement std::condition_variable via pthread_cond_clockwait() where available

std::condition_variable is currently implemented via
pthread_cond_timedwait() on systems that use pthread. This is
prob

Implement std::condition_variable via pthread_cond_clockwait() where available

std::condition_variable is currently implemented via
pthread_cond_timedwait() on systems that use pthread. This is
problematic, since that function waits by default on CLOCK_REALTIME
and libc++ does not provide any mechanism to change from this
default.

Due to this, regardless of if condition_variable::wait_until() is
called with a chrono::system_clock or chrono::steady_clock parameter,
condition_variable::wait_until() will wait using CLOCK_REALTIME. This
is not accurate to the C++ standard as calling
condition_variable::wait_until() with a chrono::steady_clock parameter
should use CLOCK_MONOTONIC.

This is particularly problematic because CLOCK_REALTIME is a bad
choice as it is subject to discontinuous time adjustments, that may
cause condition_variable::wait_until() to immediately timeout or wait
indefinitely.

This change fixes this issue with a new POSIX function,
pthread_cond_clockwait() proposed on
http://austingroupbugs.net/view.php?id=1216. The new function is
similar to pthread_cond_timedwait() with the addition of a clock
parameter that allows it to wait using either CLOCK_REALTIME or
CLOCK_MONOTONIC, thus allowing condition_variable::wait_until() to
wait using CLOCK_REALTIME for chrono::system_clock and CLOCK_MONOTONIC
for chrono::steady_clock.

pthread_cond_clockwait() is implemented in glibc (2.30 and later) and
Android's bionic (Android API version 30 and later).

This change additionally makes wait_for() and wait_until() with clocks
other than chrono::system_clock use CLOCK_MONOTONIC.<Paste>

llvm-svn: 372016

show more ...

[libc++] Use [[nodiscard]] for lock_guard, as an extension

Summary:
D64914 added support for applying [[nodiscard]] to constructors. This
commit uses that capability to flag incorrect uses of std::l

[libc++] Use [[nodiscard]] for lock_guard, as an extension

Summary:
D64914 added support for applying [[nodiscard]] to constructors. This
commit uses that capability to flag incorrect uses of std::lock_guard
where one forgets to actually create a variable for the lock_guard.

rdar://45790820

Reviewers: mclow.lists, EricWF

Subscribers: christof, jkorous, dexonsmith, libcxx-commits, Quuxplusone, lebedev.ri

Tags: #libc

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

llvm-svn: 368664

show more ...

Revert "Suppress -Wctad-maybe-unsupported on types w/o deduction guides."

Some modules builds are issuing buggy diagnostics. The cause of which is
TBD.

This reverts commit r@367770.

llvm-svn: 3677

Revert "Suppress -Wctad-maybe-unsupported on types w/o deduction guides."

Some modules builds are issuing buggy diagnostics. The cause of which is
TBD.

This reverts commit r@367770.

llvm-svn: 367777

show more ...

Suppress -Wctad-maybe-unsupported on types w/o deduction guides.

There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so

Suppress -Wctad-maybe-unsupported on types w/o deduction guides.

There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.

This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).

llvm-svn: 367770

show more ...