First, add a TEST_HAS_QUICK_EXIT macro to mirror other C11 features like
TEST_HAS_ALIGNED_ALLOC, and update the tests for that.
Second, get rid of TEST_HAS_C11_FEATURES and _LIBCPP_HAS_C11_FEATURES,
which were only used to ensure that feature macros don't get out of
sync between <__config> and "test_macros.h". This is not necessary
anymore, since we have tests for each individual macro now.
This change replaces std::make_unique with manual construction of
std::unique_ptr to make the tests compatible with C++11
(std::make_unique is a C++14 feature).
libc++ supports std::unique_ptr and std::shared_ptr even in C++03 but
with some limitations: unique_ptr_array.pass.cpp and
shared_ptr_arg.pass.cpp fail to compile in C++03 mode and need to be
disabled.
Differential Revision: https://reviews.llvm.org/D84394
Summary:
weak_ptr has two pointers (more than the 4 bytes limit), so it will not be returned in registers on ARM, even if it is trivial.
The test, therefore, will fail on ARM.
Reviewers: #libc!
Subscribers: kristof.beyls, danielkiss, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D84200
Some time ago, I introduced shortcut features like dylib-has-no-shared_mutex
to encode whether the deployment target supported shared_mutex (say). This
made the test suite annotations cleaner.
However, the problem with building Lit features on top of other Lit
features is that it's easier for them to become stale, especially when
they are generated programmatically. Furthermore, it makes the bar for
defining configurations from scratch higher, since more features have
to be defined. Instead, I think it's better to put the XFAILs in the
tests directly, which allows cleaning them up with a simple grep.
This allows passing parameters to the test suites without using
LLVM_LIT_ARGS. The problem is that we sometimes want to set some
Lit arguments on the CMake command line, but the Lit parameters in
a CMake cache file. If the only knob to do that is LLVM_LIT_ARGS,
the command-line entry overrides the cache one, and the parameters
set by the cache are ignored.
This fixes a current issue with the build bots that they completely
ignore the 'std' param set by Lit, because other Lit arguments are
provided via LLVM_LIT_ARGS on the CMake command-line.
There used to be a workaround where we'd pretend that GCC 5 didn't support
C++14 because it doesn't implement it properly. Since that workaround has
been removed (in 1eb211ada1), we need to mark a few individual tests as
failing with GCC 5.
Instead of detecting it automatically (in libc++) and relying on
_LIBCXXABI_NO_EXCEPTIONS being set explicitly (in libc++abi), always
detect whether exceptions are enabled automatically.
This commit also removes support for specifying -D_LIBCPP_NO_EXCEPTIONS
and -D_LIBCXXABI_NO_EXCEPTIONS explicitly -- those should just be inferred
from using -fno-exceptions (or an equivalent flag).
Allowing both -D_FOO_NO_EXCEPTIONS to be provided explicitly and trying
to detect it automatically is just confusing, especially since we did
specify it explicitly when building libc++abi. We should have only one
way to detect whether exceptions are enabled, but it should be robust.
As announced on libcxx-dev at [1], the old libc++ testing format is being
removed in favour of the new one. Follow-up commits will clean up the
code that is dead after the removal of this option.
[1]: http://lists.llvm.org/pipermail/libcxx-dev/2020-June/000885.html
Summary:
https://reviews.llvm.org/D82029 introduced the non-throw check for final_suspend(). There are a few tests I missed in that patch.
Fixing them here.
Reviewers: #libc, lewissbaker, modocache, ldionne
Reviewed By: #libc, ldionne
Subscribers: dexonsmith, modocache, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D82338
Similar to <concepts>, we need to protect the header and test against
inclusion and being run if concepts aren't supported by the compiler.
Differential Revision: https://reviews.llvm.org/D82171
Before this patch, the libc++ test suite first loads lit.site.cfg
(generated by CMake), and then lit.cfg. It's also possible to load
lit.cfg before lit.site.cfg and to point to a custom lit.site.cfg
file using '--param=libcxx_site_config'. However, in that case, lit.cfg
still relies on the site configuration filling up the 'config' object
like the default lit.site.cfg file does, which isn't flexible enough.
This commit simplifies the setup by having just a single Lit site config
file per CMake configuration, and always loading exactly that config file.
However, the config file to use can be selected when setting up CMake via
the LIBCXX_TEST_CONFIG setting. Furthermore, the site configs are entirely
standalone, which means that a new site config can be added that doesn't
need to conform what's expected by config.py.
Differential Revision: https://reviews.llvm.org/D81846
The Standard documents the signature of std::advance as
template <class Iter, class Distance>
constexpr void advance(Iter& i, Distance n);
Furthermore, it does not appear to put any restriction on what the type
of Distance should be. While it is understood that it should usually
be std::iterator_traits::difference_type, I couldn't find any wording
that mandates that. Similarly, I couldn't find wording that forces the
distance to be a signed type.
This patch changes std::advance to accept any type in the second argument,
which appears to be what the Standard mandates. We then coerce it to the
iterator's difference type, but that's an implementation detail.
Differential Revision: https://reviews.llvm.org/D81425
This is useful for checking runtime properties of the target system.
This is a partial re-application of 3ea9450bda. This part was tested
to work on a Windows host with a SSH executor.
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.
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.
Implements P0414R2:
* Adds support for array types in std::shared_ptr.
* Adds reinterpret_pointer_cast for shared_ptr.
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.
The challenge with measuring time in tests is that slow and/or busy
machines can cause tests to fail in unexpected ways. After this change,
three tests should be much more robust. The only remaining and tiny race
that I can think of is preemption after `--countDown`. That being said,
the race isn't fixable because the standard library doesn't provide a
way to count threads that are waiting to acquire a lock.
Reviewers: ldionne, EricWF, howard.hinnant, mclow.lists, #libc
Reviewed By: ldionne, #libc
Subscribers: dexonsmith, jfb, broadwaylamb, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D79406
This change adds test coverage for the `codecvt<char16_t, char8_t, mbstate_t>` and `codecvt<char32_t, char8_t, mbstate_t>` ctype facets added to the C++20 WD by [P0482R6](https://wg21.link/P0428R6). Note that libc++ does not implement these facets despite implementing the remainder of P0482, presumably for ABI reasons, so these tests are marked `UNSUPPORTED: libc++`.
Louis Dionne