That test is already only enabled if LIBCXX_TEST_GDB_PRETTY_PRINTERS is
enabled, which isn't the default. If someone turns on that option on
Windows, they should be able to run the test and see whatever failure
happens.
The integration between CMake and executor selection in the new format
wasn't very flexible -- only the default executor and SSH executors were
supported.
This patch makes it possible to specify arbitrary executors with the new
format. With the new testing format, a custom executor is just a script
that gets called with a command-line to execute, and some arguments like
--env, --codesign_identity and --execdir. As such, the default executor
is just run.py.
Remote execution with the SSH executor can be achived by specifying
LIBCXX_EXECUTOR="<path-to-ssh.py> --host <host>". Similarly, arbitrary
scripts can be provided.
Instead of passing file dependencies individually, assume that the
whole content of the unique test directory is a dependency. This
simplifies the test harness significantly, by making %T the directory
that contains everything required to run a test. This also removes the
need for the %{file_dependencies} substitution, which is removed by this
patch.
Furthermore, this patch also changes the harness to execute tests locally
inside %T, so as to avoid creating a separate directory for no purpose.
This will allow simplifying executors by always just copying the whole
%T, and assuming that all file dependencies are contained in it.
Superseeds https://reviews.llvm.org/D78245, which tried to make %T unique
in Lit, but which encountered push back.
The test is failing on 32-bit targets in C++03 mode. Clang produces
the following warning: 'integer literal is too large to be represented
in type 'long' and is subject to undefined behavior under C++98,
interpreting as 'unsigned long'; this literal will have type 'long
long' in C++11 onwards [-Wc++11-compat]' which is promoted to an error
and causes the test to fail.
There have been no changes in the test itself since 2019, so it looks
like the diagnostic has been updated.
Differential Revision: https://reviews.llvm.org/D81559
Unlike parameters in litConfig.params, the config isn't shared across
all test suites. For example, if we want to enable exceptions in the
tests for libcxxabi, but not in the tests for libcxx, we can't set the
enable_exceptions parameter in the litConfig object, cause it will be
used by both. Instead, setting it inside the config object solves that
problem.
This reverts commit 0c148430cf, which added an assertion in day().
The Standard doesn't allow day() to crash -- instead it says that the
result is unspecified.
Differential Revision: https://reviews.llvm.org/D70346
All compilers supported by libc++ have rvalues in C++03 mode so, there is no need for this non-rvalue overload.
Differential Revision: https://reviews.llvm.org/D80881
Before this patch, we tried detecting whether small atomics were available
without linking against libatomic. However, that's not really what we want
to know -- instead, we want to know what's required in order to support
atomics fully, which is to link against libatomic when it's provided.
That is both much simpler, and it doesn't suffer the problem that we would
not link against libatomic when small atomics didn't require it, which
lead to non-lockfree atomics never working.
Furthermore, because we understand that some platforms might not want to
(or be able to) ship non-lockfree atomics, we add that notion to the test
suite, independently of a potential extern library.
After this patch, we therefore:
(1) Link against libatomic when it is provided
(2) Independently detect whether non-lockfree atomics are supported in
the test suite, regardless of whether that means we're linking against
an external library or not (which is an implementation detail).
Differential Revision: https://reviews.llvm.org/D81190
Libc++ provides support for <thread> in C++03 as an extension. Furthermore,
it does not support any compiler that doesn't have rvalue references. It
is hence possible to provide the move constructor and move assignment
operator in C++03.
C++98 and C++03 are effectively aliases as far as Clang is concerned.
As such, allowing both std=c++98 and std=c++03 as Lit parameters is
just slightly confusing, but provides no value. It's similar to allowing
both std=c++17 and std=c++1z, which we don't do.
This was discovered because we had an internal bot that ran the test
suite under both c++98 AND c++03 -- one of which is redundant.
Differential Revision: https://reviews.llvm.org/D80926
This test is arguably fatally flawed, at least as long as C++ condition
variables are just trivial wrappers around POSIX. I've added some notes
to the test for future authors to consider.
The Standard is currently unimplementable. We have to pick between:
1. Not implementing constexpr support properly in std::array<T, 0>
2. Making std::array<T, 0> non-trivial even when T is trivial
3. Returning nullptr from std::array<T, 0>::begin()
Libc++ initially picked (1). In 77b9abfc8e, we started implementing constexpr properly, but lost the guarantee of triviality. Since it seems like both (1) and (2) are really important, it seems like (3) is the only viable option for libc++, after all. This is also what other implementations are doing.
This patch moves libc++ from (1) to (3).
It also:
- Improves the test coverage for the various ways of initializing std::array
- Adds tests for the triviality of std::array
- Adds tests for the aggregate-ness of std::array
Reviewed By: #libc, miscco, EricWF, zoecarver
Differential Revision: https://reviews.llvm.org/D80821
When the __config_site header is generated, but LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT
wasn't specified, _LIBCPP_HAS_MERGED_TYPEINFO_NAMES_DEFAULT would be defined
to 0, which was the NonUnique RTTI comparison implementation. The intent
was to use the Unique RTTI comparison implementation in that case, which
caused https://llvm.org/PR45549.
Instead, use a proper "switch" to select the RTTI comparison implementation.
Note that 0 can't be used as a value, because that is treated the same
by CMake as a variable that is just not defined.
Differential Revision: https://reviews.llvm.org/D80037
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
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 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
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
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
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
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.
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.
Vladimir Vereschaka