This changes the checking for available locales to use one program that
iterates over argv to test multiple locale names instead of checking each
name with a separate executable.
This massively speeds up running individual tests using an SSH executor
(it can take up to 10 seconds to compile and run a single test in some
emulated environments) in case no locales are installed since then all
fallback names are tested idividually. But even on a native machine
this reduces the libc++ lit startup time by ~1-2 second for me on a machine
that does not have locale data installed.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D88884
On FreeBSD we get the following error when passing zero as the requested
alignment: error: requested alignment is not a power of 2
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D88820
Use string() for convenience for testing where possible, but keep using
native() for move tests where we want to check that no allocations are
made, constructing a reference fs::path::string_type instead.
Use the right value_type in a few places.
Make the synop test check for the right types and for the expected
preferred separator.
Differential Revision: https://reviews.llvm.org/D89537
Instead of having this script be part of the OSS-Fuzz repository, I think
it makes more sense to have it alongside the rest of the fuzzing targets
in libc++.
This fixes building with libstdc++ for windows. MS STL has got
ifstream/ofstream overloads that taken wide strings though.
Differential Revision: https://reviews.llvm.org/D89539
rGcc69d211d0d65d7b introduced several uses of `printf` with format
directives `%lu` and `%ld` to format values of type `size_t` and
`ptrdiff_t` respectively.
That doesn't reliably work in all C implementations, because those
types aren't necessarily the same thing as 'long int': sometimes
they're not even the same size, and when they are the same size, they
might be officially defined as int rather than long (for example),
which causes clang to emit a diagnostic for the mismatch.
C has special-purpose printf modifier letters for these two types, so
it's safer to use them. Changed all `%lu` on `size_t` to `%zu`, and
all `%ld` on `ptrdiff_t` to `%td`.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D89545
Some platforms, like several embedded platforms, do not provide a source
of randomness through a random device. This commit makes it possible to
build and test libc++ for such platforms, i.e. without std::random_device.
Surprisingly, the only functionality that doesn't work on such platforms
is std::random_device itself -- everything else in <random> still works,
one just has to find alternative ways to seed the PRNGs.
Also, some tests had multiple death tests in them, so split them into
separate tests instead. The second death test would obviously never
get run, because the first one would kill the program before.
While this adds some convenience to the test suite, it prevents the tests
using these checkpoints from being used on systems where signals are not
available, such as some embedded systems. It will also prevent these tests
from being constexpr-friendly once e.g. std::map is made constexpr, due
to the use of statics.
Instead, one can always use a debugger to figure out exactly where a
test is failing when that isn't clear from the log output without
checkpoints.
We used <iostream> in several places where we don't actually need the
full power of <iostream>, and where using basic `std::printf` is enough.
This is better, since `std::printf` can be supported on systems that don't
have a notion of locales, while <iostream> can't.
To make it clearer this is about whether the library supports the debug
mode at all, not whether the debug mode is enabled. Per comment by Nico
Weber on IRC.
To make sure we don't store a mutable object (which could be modified by
outside code without us noticing) as the cache key, we pickle the cache
key to get a byte stream. If two keys are unequal, we know for sure they
will not have the same pickling. And if they are equal, there's a large
chance they will have the same pickling. If they don't, we might end up
not reusing a cached entry when we could have, but at least the behavior
we'll have is semantically correct.
This is needed when running the tests in Freestanding mode, where main()
isn't treated specially. In Freestanding, main() doesn't get mangled as
extern "C", so whatever runtime we're using fails to find the entry point.
One way to solve this problem is to define a symbol alias from __Z4mainiPPc
to _main, however this requires all definitions of main() to have the same
mangling. Hence this commit.
glibc supports versioning, so it's possible to build against older
version and run against newer version. This is sometimes relied on
in practice, e.g. in Fuchsia build we build against older sysroot
(equivalent to Ubuntu Trusty) to cover the broadest possible range
of host systems, but that doesn't necessarily match the system that
binary is going to run on which may have newer version, in which case
the compile test used in curr_symbol is going to fail. Using runtime
check is more reliable. This is a follow up to D56702 which addressed
one instance, this patch addresses all of the remaining ones.
Differential Revision: https://reviews.llvm.org/D88188
Some libc++ builds may want to disable support for the debug mode,
for example to reduce code size or because the current implementation
of the debug mode requires a global map. This commit adds the
LIBCXX_ENABLE_DEBUG_MODE CMake option and ties it into the test
suite.
It also adds a CI job to test this configuration going forward.
Differential Revision: https://reviews.llvm.org/D88923
These tests were only being run when _LIBCPP_DEBUG was defined, which
isn't the case by default when we run the test suite. In other words,
all these debug mode tests were never being run. This commit makes sure
they are run, and in some cases, extracts them into a file under test/libcxx
to separate them from the Standard tests.
Differential Revision: https://reviews.llvm.org/D88836
* Use an empty struct instead of a member pointer to represent this
type, so that we don't actually pass a zero member pointer at runtime.
* Mark the constructor as consteval to ensure that no code is emitted
for it whenever possible.
* Add a honeypot constructor to reject all non-int arguments, so that
the only argument that can arrive at the real constructor is the
literal 0.
This results in better generated code, and rejecting invalid comparisons
against nullptr, 0L, and so on, while also rejecting invalid comparisons
against (1-1) and similar that would be allowed if we required an
integer constant expression with value 0.
Differential Revision: https://reviews.llvm.org/D85051
After rebasing my trivially-relocatable branch, this behavior was broken...
but no libc++ unit test caught it! Add a regression test specifically for
erasing out of a vector.
Differential Revision: https://reviews.llvm.org/D88421
We're technically not allowed by the Standard to call ::operator new in
constexpr functions like __libcpp_allocate. Clang doesn't seem to complain
about it, but GCC does.
fdc41e11f was reverted in e46c1def5 because it broke the C++11 build.
We shouldn't be using enable_if_t in C++11, instead we must use
enable_if<...>::type.
This reverts commit fdc41e11f9. It causes the
libcxx/modules/stds_include.sh.cpp test to fail with:
libcxx/include/ostream:1039:45: error: no template named 'enable_if_t'; did you mean 'enable_if'?
template <class _Stream, class _Tp, class = enable_if_t<
Still investigating what's causing this and reverting in the meantime to get
the bots green again.
Libc++ had an issue where nonsensical code like
decltype(std::stringstream{} << std::vector<int>{});
would compile, as long as you kept the expression inside decltype in
an unevaluated operand. This turned out to be that we didn't implement
LWG1203, which clarifies what we should do in that case.
rdar://58769296
This commit adds std::construct_at, and marks various members of
std::allocator_traits and std::allocator as constexpr. It also adds
tests and turns the existing tests into hybrid constexpr/runtime tests.
Thanks to Richard Smith for initial work on this, and to Michael Park
for D69803, D69132 and D69134, which are superseded by this patch.
Differential Revision: https://reviews.llvm.org/D68364
Mitsuru Kariya reported the map operations insert_or_assign with a hint
violates the complexity requirement. The function no longer uses a lower_bound,
which caused the wrong complexity.
Fixes PR38722: [C++17] std::map::insert_or_assign w/ hint violate complexity requirements
Differential Revision: https://reviews.llvm.org/D62779
We don't support GCC in C++03 mode, and Clang provides variadic templates
even in C++03 mode. So there's effectively no supported compiler that
doesn't support variadic templates.
This effectively gets rid of all uses of _LIBCPP_HAS_NO_VARIADICS, but
some workarounds for the lack of variadics remain.
When statically linking libc++ on some systems, the streams are not
initialized early enough, which causes all kinds of issues. This was
reported e.g. in http://llvm.org/PR28954, but also in various open
source projects that use libc++.
Fixes http://llvm.org/PR28954.
Differential Revision: https://reviews.llvm.org/D31413
https://llvm.org/PR45099 notes (correctly) that we're inconsistent in memory
allocation in `std::any`. We allocate memory with `std::allocator<T>::allocate`,
construct with placement new, destroy by calling the destructor directly, and
deallocate by calling `delete`. Most of those are customizable by the user,
but in different ways.
The standard is silent on how these things are to be accomplished.
This patch makes it so we use `allocator_traits<allocator<T>>` for all
of these operations (allocate, construct, destruct, deallocate).
This is, at least, consistent.
Fixes https://llvm.org/PR45099.
Differential Revision: https://reviews.llvm.org/D81133
This test tries to create a 2 GiB std::string, catching the bad_alloc
exception if the allocation fails. However, for no-exceptions builds
there is no way for the error to be reported, so this crashes with a
null pointer dereference.
Differential revision: https://reviews.llvm.org/D87682
This patch makes `std::rotate` a constexpr. In doing so, this patch also
updates the internal `__move` and `__move_backward` funtions to be
constexpr.
This patch was previously reverted in ed653184ac because it was missing
some UNSUPPORTED markup for older compilers. This commit adds it.
Differential Revision: https://reviews.llvm.org/D65721
The standard does not require the constructor `strstreambuf(streamsize alsize_arg = 0)`
leave the stream array unallocated when called with parameter `alsize_arg > 0`.
Conformant implementations of this constructor may allocate minimal `alsize_arg`
number of bytes forcing `str()` method to return non-null pointer.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D72465
cppreference lists the support for this paper as partial.
I found 4 functions which the paper marks as `constexpr`,
but did not use the appropriate macro.
Differential Revision: https://reviews.llvm.org/D84275
This patch makes `std::rotate` a constexpr. In doing so, this patch also
updates the internal `__move` and `__move_backward` funtions to be
constexpr.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D65721
In C++20, since P0896R4, std::ostream_iterator and std::ostreambuf_iterator
must have std::ptrdiff_t instead of void as a difference_type.
Tests by Casey Carter (thanks!).
Differential Revision: https://reviews.llvm.org/D87459
Instead, use with_system_cxx_lib with various compile-only tests to ensure
that we're getting compile-time errors, as expected. This follows the
lead of ec46cfefe8.
The needs of back-deployment testing currently require two different
ways of running the test suite: one based on the deployment target,
and one based on the target triple. Since the triple includes all the
information we need, it's better to have just one way of doing things.
Furthermore, `--param platform=XXX` is also supersedded by using the
target triple. Previously, this parameter would serve the purpose of
controling XFAILs for availability markup errors, however it is possible
to achieve the same thing by using with_system_cxx_lib only and using
.verify.cpp tests instead, as explained in the documentation changes.
The motivation for this change is twofold:
1. This part of the Lit config has always been really confusing and
complicated, and it has been a source of bugs in the past. I have
simplified it iteratively in the past, but the complexity is still
there.
2. The deployment-target detection started failing in weird ways in
recent Clangs, breaking our CI. Instead of band-aid patching the
issue, I decided to remove the complexity altogether by using target
triples even on Apple platforms.
A follow-up to this commit will bring the test suite in line with
the recommended way of handling availability markup tests.
Currently the libcxx/atomics/ext-int.verify.cpp test fails when run with
-std=c++03 because there's an extra error due to using list initialization. Fix
this by using parentheses instead.
D56913 introduced the _LIBCPP_FREESTANDING macro and guarded its
definition by:
#ifndef __STDC_HOSTED__
# define _LIBCPP_FREESTANDING
#endif
However, __STDC_HOSTED__ is defined as 0 in freestanding implementations
instead of undefined, which means that _LIBCPP_FREESTANDING would never
get defined. This patch corrects the above as:
#if __STDC_HOSTED__ == 0
# define _LIBCPP_FREESTANDING
#endif
Differential Revision: https://reviews.llvm.org/D86055
This commit re-applies 99f3b231cb, which was reverted in 8142425727
because it broke the modules build. The modules failure was a circular
dependency between the Darwin module and __config. Specifically, the
issue was that if <__config> includes a system header, the std_config
module depends on the Darwin module. However, the Darwin module already
depends on the std_config header because some of its headers include
libc++ headers like <ctype.h> (they mean to include the C <ctype.h>,
but libc++ headers are first in the header search path).
This is fixed by moving the workaround to <ctime> only.
https://llvm.org/PR47208
rdar://68157284
This reverts commit 99f3b231cb. It breaks
libcxx/modules/stds_include.sh.cpp on macOS as the new include to sys/cdefs.h
causes a dependency from __config to the Darwin module (which already has
a dependency on __config). This cyclic dependency breaks compiling the std
module which breaks compiling pretty much every program with ToT libc++ and
enabled modules.
I'll revert for now to get the bots green again. Sorry for the inconvenience.
timespec_get is not available in Apple SDKs when (__DARWIN_C_LEVEL >= __DARWIN_C_FULL)
isn't true, which leads to libc++ trying to import ::timespec_get into
namespace std when it's not available. This issue has been reported to
Apple's libc, but we need a workaround in the meantime.
https://llvm.org/PR47208
rdar://68157284
This commit adds the first from-scratch configuration files for running
the libc++ test suite without using the old configuration:
- libcxx-trunk-shared.cfg.py:
Runs the test suite against a trunk libc++ shared library.
- libcxx-trunk-static.cfg.py:
Runs the test suite against a trunk libc++ static library.
Differential Revision: https://reviews.llvm.org/D81866
This implements the part of P0619R4 related to the default allocator.
This is incredibly important, since otherwise there is an ABI break
between C++17 and C++20 w.r.t. the default allocator's size_type on
platforms where std::size_t is not the same as std::make_unsigned<std::ptrdiff_t>.
We're (temporarily) disabling ExtInt for the '__atomic' builtins so we can better design their behavior later. The idea is until we do an audit/design for the way atomic builtins are supposed to work with _ExtInt, we should leave them restricted so they don't limit our future options, such as by binding us to a sub-optimal implementation via ABI.
Example after this change:
$ cat test.c
void f(_ExtInt(64) *ptr) {
__atomic_fetch_add(ptr, 1, 0);
}
$ clang -c test.c
test.c:2:22: error: argument to atomic builtin of type '_ExtInt' is not supported
__atomic_fetch_add(ptr, 1, 0);
^
1 error generated.
Differential Revision: https://reviews.llvm.org/D84049
We don't support GCC in C++03 mode, and Clang provides rvalue references
even in C++03 mode. So there's effectively no supported compiler that
doesn't support rvalue references.
Differential Revision: https://reviews.llvm.org/D84943
Add shared_ptr tests where the element type and pointer type aren't 'convertible' but are 'compatible'.
Responding to a comment from D81414.
Differential Revision: https://reviews.llvm.org/D81532
Block.h is a pretty common name, which can lead to nasty collisions with
user provided headers. Since we're only getting a few simple declarations
from the header, it's better to declare them manually than to include the
header.
rdar://66384326
Differential Revision: https://reviews.llvm.org/D85035
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
Casey Carter