Summary: The implementation of P1152R4 in Clang has resulted in some deprecation warnings appearing in the libc++ and libc++abi test suite. Fix or suppress these warnings.
Reviewers: mclow.lists, EricWF
Subscribers: christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68879
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@375307 91177308-0d34-0410-b5e6-96231b3b80d8
* Add the conventional `return 0` to `main` in `variant.assign/conv.pass.cpp` and `variant.ctor/conv.pass.cpp`
* Fix some MSVC signed-to-unsigned conversion warnings by replacing `int` literarls with `unsigned int` literals
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@374723 91177308-0d34-0410-b5e6-96231b3b80d8
`make_optional<string>(4, 'X')` passes `4` (an `int`) as the first argument to `string`'s `(size_t, charT)` constructor, triggering a signed/unsigned mismatch warning when compiling with MSVC at `/W4`. The incredibly simple fix is to instead use an unsigned literal (`4u`).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@374684 91177308-0d34-0410-b5e6-96231b3b80d8
* Silence unused-local-typedef warnings: `map.cons/assign_initializer_list.pass.cpp` (and the `set.cons` variant) uses a local typedef only within `LIBCPP_ASSERT`s, so clang diagnoses it as unused when testing non-libc++.
* Add missing include: `c.math/abs.pass.cpp` uses `std::numeric_limits` but failed to `#include <limits>`.
* Don't test non-type: A "recent" change to `meta.trans.other/underlying_type.pass.cpp` unconditionally tests the type `F` which is conditionally defined.
* Use `hash<long long>` instead of `hash<short>` with `int` in `unordered_meow` deduction guide tests to avoid truncation warnings.
* Convert `3.14` explicitly in `midpoint.float.pass` since MSVC incorrectly diagnoses `float meow = 3.14;` as truncating.
Differential Revision: https://reviews.llvm.org/D68681
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@374248 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
LWG 3158 marks the allocator_arg_t constructor of std::tuple as
conditionnally explicit based on whether the default constructors
of the tuple's members are explicitly default constructible.
This was previously committed as r372778 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/D65232
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@373092 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@372983 91177308-0d34-0410-b5e6-96231b3b80d8
Users should only get the assert() macros if they explicitly include
them.
Found after switching from the GNU C++ stdlib to the LLVM C++ stdlib.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@372963 91177308-0d34-0410-b5e6-96231b3b80d8
We don't support GCC 4 and older according to the documentation, so
we should pretend it doesn't exist.
This is a re-application of r372787.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@372916 91177308-0d34-0410-b5e6-96231b3b80d8
This declaration was previously missing despite appearing in the
synopsis. Users are still required to include <ostream> to get the
definition of the streaming operator.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@372909 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
LWG 3158 marks the allocator_arg_t constructor of std::tuple as
conditionnally explicit based on whether the default constructors
of the tuple's members are explicitly default constructible.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65232
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@372778 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@372777 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@372016 91177308-0d34-0410-b5e6-96231b3b80d8
exceptions are disabled.
The patch was reverted due to some confusion about non-movable types. ie
types
that explicitly delete their move constructors. However, such types do
not meet
the requirement for `MoveConstructible`, which is required by
`std::vector`:
Summary:
`std::vector<T>` is free choose between using copy or move operations
when it
needs to resize. The standard only candidates that the correct exception
safety
guarantees are provided. When exceptions are disabled these guarantees
are
trivially satisfied. Meaning vector is free to optimize it's
implementation by
moving instead of copying.
This patch makes `std::vector` unconditionally move elements when
exceptions are
disabled. This optimization is conforming according to the current
standard wording.
There are concerns that moving in `-fno-noexceptions`mode will be a
surprise to
users. For example, a user may be surprised to find their code is slower
with
exceptions enabled than it is disabled. I'm sympathetic to this
surprised, but
I don't think it should block this optimization.
Reviewers: mclow.lists, ldionne, rsmith
Reviewed By: ldionne
Subscribers: zoecarver, christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62228
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@371867 91177308-0d34-0410-b5e6-96231b3b80d8
This was reported as part of a bug report that ended up being a
duplicate for r340609, but I'm adding the test case since it's
ever so slightly different from what we had before.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@370109 91177308-0d34-0410-b5e6-96231b3b80d8
In r369429, I hoisted a floating point computation to a variable in order
to remove a warning. However, it turns out this doesn't play well with
floating point arithmetic. This commit reverts r369429 and instead casts
the result of the floating point computation to remove the warning.
Whether hoisting the computaiton to a variable should give the same
result can be investigated independently.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@369693 91177308-0d34-0410-b5e6-96231b3b80d8
On systems where sizeof(long) == sizeof(int)
the current tests failed. This commit updates
those tests to work on all systems.
std::abs has specific long specializations
which can be used instead.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@369437 91177308-0d34-0410-b5e6-96231b3b80d8
By stashing the computation of `E::max() - E::min()` in a variable, we
avoid the warning introduced in r367497. Note that we use `auto` to
avoid having to deduce the type of the computation, which is not a
problem since Clang provides `auto` as an extension even in C++03 (and
we disable warnings related to using C++11 extensions in the test suite).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@369429 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The resolution of LWG 3199 makes sure that input-streaming into an empty bitset
does not set the failbit on the input stream.
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65105
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@369422 91177308-0d34-0410-b5e6-96231b3b80d8
On some systems char is unsigned.
If that is the case, we will now
test signed char twice in std::abs.
NFC. Fixes the build bots.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@369413 91177308-0d34-0410-b5e6-96231b3b80d8
In r368882, I enabled those tests for all AppleClang's above version 9.
However, it turns out that the feature is only supported starting with
AppleClang 10.0.1, not AppleClang 10.0.0. This commit fixes that hole.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@369409 91177308-0d34-0410-b5e6-96231b3b80d8
Like CTAD for std::unordered_set, AppleClang 9's support for CTAD is
insufficient. I suspect the corresponding LLVM Clang is broken too,
but we don't seem to have testers using that Clang.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@368911 91177308-0d34-0410-b5e6-96231b3b80d8
The operator""y and operator""d will eventually be supported by
AppleClang, but no released version supports them at the moment.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@368749 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We were using implicit deduction guides instead of explicit ones,
however the implicit ones don't do work anymore when changing the
constructors.
This commit adds the actual guides specified in the Standard to make
libc++ (1) closer to the Standard and (2) more resistent to changes
in std::tuple's constructors.
Reviewers: Quuxplusone
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65225
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@368599 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
The first attempt to commit this failed because it exposed a bug in the
tests for modules. Now that this has been fixed, it should be safe to
commit this.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@367903 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@367770 91177308-0d34-0410-b5e6-96231b3b80d8
[cpp.predefined]p2:
__STDCPP_THREADS__
Defined, and has the value integer literal 1, if and only if a program
can have more than one thread of execution .
Also define it only if it's not defined already, since it's supposed
to be defined by the compiler.
Also move it from thread to __config (which requires setting it only
if _LIBCPP_HAS_NO_THREADS is not defined).
Part of PR33230. The intent is to eventually make the compiler define
this instead.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@367316 91177308-0d34-0410-b5e6-96231b3b80d8
