This commit adds missing support for constexpr in std::array under all
standard modes up to and including C++20. It also transforms the <array>
tests to check for constexpr-friendliness under the right standard modes.
Fixes https://llvm.org/PR40124
Fixes rdar://57522096
Supersedes https://reviews.llvm.org/D60666
Differential Revision: https://reviews.llvm.org/D80452
Summary: Update status page and test synopsis. Add synopsis in <cmath>.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D80456
Summary: a4b8ee6 made all MoveOnly members constexpr but, some members and constructors contain expressions that are only valid in C++14 and later. This patch prefixes those methods and constructors with TEST_CONSTEXPR_CXX14.
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80482
Don't use std::filesystem APIs for CWDGuard, use POSIX functions
instead. This way the tests don't rely on the correctness of
the functionality they're testing.
Differential Revision: https://reviews.llvm.org/D78200
__test_has_construct.
In C++17 some tests started failing after a521532aa1. This fixes those errors by suppressing the deprecation warning when calling `construct` in `__test_has_construct`. This is the same solution as `__has_destroy_test` already uses.
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80481
Summary:
Libcxx only supports compilers with variadics. We can safely remove all "fake" variadic overloads of allocator_traits::construct.
This also provides the correct behavior if anything other than exactly one argument is supplied to allocator_traits::construct in C++03 mode.
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80067
Summary:
As described in the bug report:
The commit a8b9f59e8caf378d56e8bfcecdb22184cdabf42d "Implement feature test macros using a script" added test features macros for libc++. Among others, it added `__cpp_lib_hardware_interference_size`. However, there is nothing like std::hardware_constructive_interference_size nor std::hardware_destructive_interference_size, that should be in header <new>.
* https://bugs.llvm.org/show_bug.cgi?id=41423
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D80431
The two functions don't throw, and the generated code is better when
we explicitly tell the compiler that the functions are noexcept. This
isn't an ABI break because the signatures of the functions stay the
same with or without noexcept.
Fixes https://llvm.org/PR46016
Differential Revision: https://reviews.llvm.org/D80379
The tests had copy-paste errors which started showing when an
unused-variable warning started being emitted after we made
the MoveOnly type constexpr (in a4b8ee6422).
Summary:
This LWG issue states that the result of `year_month_day_last::day()` is implementation defined if `ok()` is `false`.
However, from user perspective, calling `day()` in this situation will lead to a (possibly difficult to find) crash.
Hence, I have added an assertion to warn user at least when assertions are enabled.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D70346
Instead of linking the tests against a library in some version of the
SDK, always link against the latest library, but still run against the
specified back-deployment target dylib.
This makes more sense since what we're really trying to test is that
the current library can be used to produce binaries that run on some
deployment target -- not that linking against the library in some
previous SDK makes that possible.
This solves an additional issue that when linking against a system dylib,
the -rpath argument given to the tests is ignored because the install_name
of the system library we link against is absolute.
rdar://63241847
Summary: Compilation with -DLIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY was failing due to missing declarations of functions used in libcxx/include/atomic. The lines this commit affects are the places where those functions are defined, now moved to be always defined.
Reviewers: #libc, ldionne
Reviewed By: #libc, ldionne
Subscribers: miyuki, dexonsmith, ldionne, jfb, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80372
Tests for `std::system_error` constructor marked as slightly non-portable.
One (but not the only one) reason for such non-portability is that these
tests assume the default locale to be set to "C" (or "POSIX").
However, the default locale for the process depends on OS and
environment. This patch adds explicit setting of the correct
locale expected by the tests.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D72456
This change removes both the member function swap and the free function
overload of swap for std::span. While swap is a member and overloaded
for every other container in the standard library [1], it is neither a
member function nor a free function overload for std::span [2].
Thus the corresponding implementation should be removed.
[1] https://eel.is/c++draft/libraryindex#:swap
[2] https://eel.is/c++draft/span.overview
Differential Revision: https://reviews.llvm.org/D69827
Summary: All supported compilers have rvalues and variadics so we can safely remove the overloads of allocator::construct which are only enabled on compilers without rvalues and variadics.
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80068
Summary: All supported compilers have rvalues and variadics so we can safely remove the overloads of allocator::construct which are only enabled on compilers without rvalues and variadics.
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80068
Summary: The default constructor for shared_ptr and shared_ptr::__enable_weak_this are both noexcept so, shared_ptr::__create_with_control_block can also be marked noexcept.
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80070
Summary: In std::functional moves the reference out of the `__callable` implementation and replaces `_EnableIfCallable` with `_EnableIfLValueCallable` (`_EnableIfLValueCallable` passes `__callable` an lvalue reference type).
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80071
These two tests were clumsily using time measurements to determine
whether std::lock_guard was working correctly. In practice, this
approach merely verified that the underlying lock properly waits.
Now these two tests verify that lock is acquired, not dropped
prematurely, and finally, actually dropped at the end of the scope.
Like other uses of ALLOW_RETRIES, this test tried to verify that an API
returned "quickly" but quick is not safe to define given slow and/or
busy machines.
Instead, we now verify that these "wait" APIs actually wait, which the
old test did not.
* improve coverage in `span`'s "conversion from `std::array`" test, while eliminating MSVC diagnostics about `testConstructorArray<T>() && testConstructorArray<const T, T>()` being redundant when `T` is already `const`.
* Remove use of `is_assignable` that triggers UB due to an insufficiently-complete type argument in `std::function`'s assignment operator test.
* Don't test that `shared_ptr` initialization from an rvalue triggers the lvalue aliasing constructor on non-libc++; this is not the case for Standard Libraries that implement LWG-2996. (Ditto, I'd simply remove this but it's your library ;).)
Differential Revision: https://reviews.llvm.org/D80030
We already set it using -rpath when linking test executables, and using
DYLD_LIBRARY_PATH causes problems when running other commands that
shouldn't run against the just-built libc++ (e.g. `ls` in a ShTest).
rdar://63241847
Since we're using the new testing format, DYLD_LIBRARY_PATH is not passed
to the compiler -- it's only passed to the programs we run as an argument
to the %{exec} substitution.
This is already handled by setting cxx_runtime_root instead -- I don't
see a reason to have two ways of setting the runtime path of the library
we're running against.
Because of Python's funny scoping rules with lambdas, we were always
using the value of `macro` as set in the last iteration of the loop.
This problem was introduced by e7bdfba4f0.
Otherwise, specifying (for example) the libc++.dylib from macos10.13
but the libc++abi.dylib from macos10.12 would end up adding library
paths for both the 10.12 and 10.13 dylibs, which would each contain
a copy of both libc++abi.dylib and libc++.dylib. By using a separate
directory for libc++.dylib and libc++abi.dylib, those do not conflict
anymore.
The back-deployment roots were updated to match this change.
This implements the relaxed requirements on the std::array constructors of span,
where the type only needs to be convertible to the element type of the span.
Note that the previous tests were not sufficient, as the const array<T, n> constructor
was only tested for compile time and the array<T, N> only during runtime.
Restructure the tests so that we can test conversions as well as both constructors.
Differential Revision: https://reviews.llvm.org/D75706
The default constructor of a static span requires _Extent == 0 so
SFINAE it out rather than using a static_assert
Differential Revision: https://reviews.llvm.org/D71994
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
These two tests do not use the "thread sleeps X milliseconds" pattern
that other libcxx tests use, so all we can do in order to remove
ALLOW_RETRIES workaround is remove the assumption that measuring the
"quick" return of `wait()` is possible (it is not). Let the test harness
verify overall that `wait()` does not hang.
As a bonus, have the spin-waiting threads `yield()`, which is what well
behaved code should do.
When grepping for unused features in the test suite, we will now find
those features and where they are defined, as opposed to thinking they
are dead features.
This test tried to verify that "wait()" returned quickly but "quick" is
impossible to define given a busy and/or slow system.
Instead, I've refactored the test to verify that `wait()` actually
waits which the old test did not verify.
Summary:
This LWG issue states that the result of `year_month_day_last::day()` is implementation defined if `ok()` is `false`.
However, from user perspective, calling `day()` in this situation will lead to a (possibly difficult to find) crash.
Hence, I have added an assertion to warn user at least when assertions are enabled.
I am however not aware of the libc++ stand on the desired behaviour.
Reviewers: ldionne, mclow.lists, EricWF, #libc
Reviewed By: ldionne, #libc
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D70346
Implements P0414R2:
* Adds support for array types in std::shared_ptr.
* Adds reinterpret_pointer_cast for shared_ptr.
Re-committing now that the leaking tests are fixed.
Differential Revision: https://reviews.llvm.org/D62259
Operating systems are best effort by default, so we cannot assume that
sleep-like APIs return as soon as we'd like.
Even if a sleep-like API returns when we want it to, the potential for
preemption means that attempts to measure time are subject to delays.