Move `iter_swap.pass.cpp` into a new subdirectory: `iterator.cust.swap`
for symmetry with the neighboring subdirectory `iterator.cust.move`.
Differential Revision: https://reviews.llvm.org/D116992
Introduce `__fits_in_sso()` to put the constexpr tests into a central place.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D116487
There are a lot of
```
#if _LIBCPP_DEBUG_LEVEL == 2
__get_db()->__insert_c(this);
#endif
```
This patch introduces `__debug_db_insert_c()` to put the `#if` in one central place.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D116947
In D116873 I did this for libunwind prior to defining a new install path
variable. But I think the change is good on its own, and libc++{,abi}
could also use it.
libc++ needed the base header var defined above the conditional part to
use it for the prefi+ed headers in the non-target-specific case. For
consistency, I therefore put the unconditional ones above for all 3
libs, which is why I touched the libunwind code (seeing that it had the
core change already)
Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D116988
... even when `!defined(_LIBCPP_VERSION)`. (Note that the previous definition for this case - `((void)0);` - is ill-formed at namespace scope.) Ditto for `LIBCPP_ASSERT`, `LIBCPP_ASSERT_NOEXCEPT`, `LIBCPP_ASSERT_NOT_NOEXCEPT`, and `LIBCPP_ONLY`.
Differential Revision: https://reviews.llvm.org/D116880
That will make it easier to change the behavior of the arc4random()
based implementation. Note that in particular, the eval.pass.cpp test
used to work with non "/dev/random" based implementations because we'd
throw an exception upon constructing the random_device. This patch makes
the intent of the test clearer.
The NFC part of D116809. We still want to enforce this in CI,
but the mechanism for that is still to-be-determined.
Differential Revision: https://reviews.llvm.org/D116809
Use the zx_clock_get_monotonic system call directly rather than
going through the POSIX clock_gettime function. The libc function
is a trivial wrapper around the system call, and is not a standard C
function. Avoiding it reduces the Fuchsia libc ABI surface that
libc++ depends on.
Reviewed By: phosek, ldionne, #libc
Differential Revision: https://reviews.llvm.org/D116606
Before this patch, the user needed to specialize both of
`is_placeholder<MyType>` and `is_placeholder<const MyType>`.
After this patch, only the former is needed (although the
latter is harmless if provided).
The new tests don't actually fail unless return type deduction
is used, which is a C++14 feature. Specializing `is_placeholder`
is still allowed in C++11, though.
Fixes#51095.
Differential Revision: https://reviews.llvm.org/D116388
The documentation CI job is very cheap, so we can afford to keep it
around even with reduced capacity. This commit fixes the documentation
(which had an invalid reference in it) and re-enables that CI step.
Differential Revision: https://reviews.llvm.org/D116897
Casey Carter says, "We run std/thread/thread.mutex/thread.lock.algorithm/lock.pass.cpp
on every CI and it works fine with MSVC STL. I'm guessing this annotation predates
Billy's rewrite of std::lock in 2017-ish."
Differential Revision: https://reviews.llvm.org/D116712
The reason for those nested namespaces is explained in D115315:
> AIUI, this keeps the CPO's own type from ADL'ing into the `std::ranges`
> namespace; e.g. `foobar(std::ranges::uninitialized_default_construct)`
> should not consider `std::ranges::foobar` a candidate, even if
> `std::ranges::foobar` is not a CPO itself. Also, of course, consistency
> (Chesterton's Fence, the economist's hundred-dollar bill): if it were
> safe to omit the namespace, we'd certainly want to do it everywhere,
> not just here.
This makes these three niebloids more consistent with the other Ranges
niebloids we've already implemented, such as the `ranges::begin` group
and the `ranges::uninitialized_default_construct` group.
FWIW, we still have three different indentation-and-comment styles
among these three groups.
Differential Revision: https://reviews.llvm.org/D116569
When building libcxx, libcxxabi, and libunwind the build environment may
specify any number of sanitizers. For some build feature tests these
sanitizers must be disabled to prevent spurious linking errors. With
-fsanitize= this is straight forward with -fno-sanitize=all. With
-fsanitize-coverage= there is no -fno-sanitize-coverage=all, but there
is the equivalent undocumented but tested -fsanitize-coverage=0.
The current build rules fail to disable 'trace-pc-guard'. By disabling
all sanitize-coverage flags, including 'trace-pc-guard', possible
spurious linker errors are prevented. In particular, this allows libcxx,
libcxxabi, and libunwind to be built with HonggFuzz.
CMAKE_REQUIRED_FLAGS is extra compile flags when running CMake build
configuration steps (like check_cxx_compiler_flag). It does not affect
the compile flags for the actual build of the project (unless of course
these flags change whether or not a given source compiles and links or
not). So libcxx, libcxxabi, and libunwind will still be built with any
specified sanitize-coverage as before. The build configuration steps
(which are mostly checking to see if certain compiler flags are
available) will not try to compile and link "int main() { return 0;}"
(or other specified source) with sanitize-coverage (which can fail to
link at this stage in building, since the final compile flags required
are yet to be determined).
The change to LIBFUZZER_CFLAGS was done to keep it consistent with the
obvious intention of disabling all sanitize-coverage. This appears to
be intentional, preventing the fuzzer driver itself from showing up in
any coverage calculations.
Reviewed By: #libunwind, #libc, #libc_abi, ldionne, phosek
Differential Revision: https://reviews.llvm.org/D116050
In the test files, replace the old-style tests with a simple static_assert,
matching the current style as depicted in e.g.
`ranges_uninitialized_default_construct.pass.cpp`.
Preserve `is_function_like` (but renamed to `is_niebloid`) at
ldionne's request. The removal of this test helper will happen
in D116570 if at all.
Differential Revision: https://reviews.llvm.org/D116384
This should have been done in 6a6a80e88e, but buildkite was down so I
hadn't noticed. This brings this test file into line with several others
in this directory.
z/OS doesn't support fopen64() functions. Modify the preprocessor directive for z/OS to use fopen() instead.
Reviewed By: #libc, abhina.sreeskantharajan, muiez, ldionne
Differential Revision: https://reviews.llvm.org/D111226
Although we moved to Github Issues. The bug report message refers to
Bugzilla still. This patch tries to update these URLs.
Reviewed By: MaskRay, Quuxplusone, jhenderson, libunwind, libc++
Differential Revision: https://reviews.llvm.org/D116351
This reverts commit 640beb38e7.
That commit caused performance degradtion in Quicksilver test QS:sGPU and a functional test failure in (rocPRIM rocprim.device_segmented_radix_sort).
Reverting until we have a better solution to s_cselect_b64 codegen cleanup
Change-Id: Ibf8e397df94001f248fba609f072088a46abae08
Reviewed By: kzhuravl
Differential Revision: https://reviews.llvm.org/D115960
Change-Id: Id169459ce4dfffa857d5645a0af50b0063ce1105
The fix in D116381 makes an existing exception message wrong. This
improves the message and fixes the associated unit tests.
Note other message can be also be improved, but that will be done later.
Changing these messages may cause merge conflicts with other patches
that are under review or WIP.
Depends on D116381
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D116495
@CaseyCarter reported that the tests for the std-format-spec rejects leading
zeroes for precision, which the Standard does not require. The Standard allows
them. Only for precision, not for the width or an arg-id.
Fixes the precision parser and adds some test for the arg-id since they
were missing.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D116381
Remove duplicate header includes from `<algorithm>` and reorder the includes
Reviewed By: Quuxplusone, ldionne, Mordante, #libc, jloser
Spies: jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D116507
`__cpp_lib_type_identity` was implemented way back in cf49ccd0 (Clang 8),
probably before the feature-test macro had been settled on.
`__cpp_lib_string_resize_and_overwrite` will be added by D113013 so I didn't add it here.
Fixes#46605.
Differential Revision: https://reviews.llvm.org/D116433
For example, `std::ranges::range<Holder<Incomplete>*>` should be
well-formed false, not a hard error at compile time.
Differential Revision: https://reviews.llvm.org/D116239
The big change here is that they now work as intended for rvalues,
e.g. `ranges::cbegin(std::string_view("hello"))`.
Also, add tests verifying their return types.
Differential Revision: https://reviews.llvm.org/D116199
If `__first == __middle`, then `partial_sort` is a no-op; don't
bother to iterate all the way from `__middle` to `__end`.
Fixes#49431.
Differential Revision: https://reviews.llvm.org/D116296
AFAICT, Cpp17InputIterators are not required to be default constructible,
since that requirement is added in Cpp17ForwardIterator. Hence, our
archetype for Cpp17InputIterator should not be default constructible.
Removing that constructor has a ripple effect on a couple of tests that
were making incorrect assumptions. Notably:
- Some tests were using cpp17_input_iterator as a sentinel for itself.
That is not valid, because a cpp17_input_iterator is not semiregular
anymore after the change (and hence it doesn't satisfy sentinel_for).
- Some tests were using a stride-counted cpp17_input_iterator as the
sentinel for a range. This doesn't work anymore because of the problem
above, so these tests were changed not to check stride counts for
input iterators.
- Some tests were default constructing cpp17_input_iterator when a simple
alternative was available -- those have been changed to use that alternative.
Differential Revision: https://reviews.llvm.org/D115806
Some headers which require the version header depend on other headers to
provide it. Include the version header in all top-level headers to make
sure a header cleanup can't remove the version header.
Note this doesn't add the version header to the c headers.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D116172
Use the zx_cprng_draw system call directly rather than going
through the libc getentropy function. The libc function is a
trivial wrapper around the system call, and is not a standard C
function. Avoiding it reduces the Fuchsia libc ABI surface that
libc++ depends on.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D116498
In D116472 we created conditionally defined variables for the tools to
unbreak the legacy build where they are in `llvm/tools`.
The runtimes are not tools, so that flexibility doesn't matter. Still,
it might be nice to define (unconditionally) and use the variable for
the runtimes simply to make the code a bit clearer and document what is
going on.
Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path.
Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D116477
There is an ongoing CI outage with our Linux nodes, so I temporarily
set up a couple of nodes. These nodes will be much slower than the
usual ones and there's only a few of them, so I am temporarily disabling
most of our CI to keep things working.
Line 1140 is a duplicate of line 1119; it tests the two-argument version
of std::hypot, whereas all the lines in this section are supposed to be
testing the C++17 three-argument version. Remove the erroneous duplicated line.
Split out of D116295.
Some individual test files verify the CPO under test satisfies
`semiregular` concept. This is redundant since it is already part of the test
in verifying whether the entity is indeed a CPO in
`libcxx/test/std/library/description/conventions/customization.point.object/cpo.compile.pass.cpp`.
Differential Revision: https://reviews.llvm.org/D116173
We didn't support noop_coroutine for GCC in previous conforming patch.
So that GCC couldn't use noop_coroutine() defined in <coroutine>. And
after this patch, GCC should be able to compile the whole <coroutine>
header.
Reviewed By: Quuxplusone
Differential Revision: https://reviews.llvm.org/D116144
It was missing the cast to `bool` in `bool(__t.empty())`.
It was wrongly using `std::forward` in some places.
Differential Revision: https://reviews.llvm.org/D115312
During the review of D115991 @vitaut pointed out the enum shouldn't
depend on whether or not _LIBCPP_HAS_NO_INT128 is defined. The current
implementation lets the enum's ABI depend on this configuration option
without a good cause.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D116120
These headers have stabilized; we don't expect anyone to be
blindly clang-formatting them anymore.
Leave the comments in `__format/*.h` for Mark to remove at his leisure.
Clang is gaining `auto(x)` support in D113393; sadly there
seems to be no feature-test macro for it. Zhihao is opening
a core issue for that macro.
Use `_LIBCPP_AUTO_CAST` where C++20 specifies we should use `auto(x)`;
stop using `__decay_copy(x)` in those places.
In fact, remove `__decay_copy` entirely. As of C++20, it's purely
a paper specification tool signifying "Return just `x`, but it was
perfect-forwarded, so we understand you're going to have to call
its move-constructor sometimes." I believe there's no reason we'd
ever need to do its operation explicitly in code.
This heisenbugs away a test failure on MinGW; see D112214.
Differential Revision: https://reviews.llvm.org/D115686
As discussed with ldionne. The problem with this static_assert
is that it makes ranges::begin a pitfall for anyone ever to use
inside a constraint or decltype. Many Ranges things, such as ranges::size,
are specified as "Does X if X is well-formed, or else Y if Y is well-formed,
or else `ranges::end(t) - ranges::begin(t)` if that is well-formed, or else..."
And if there's a static_assert hidden inside `ranges::begin(t)`, then you get
a hard error as soon as you ask the question -- even if the answer would have
been "no, that's not well-formed"!
Constraining on `requires { t + 0; }` or `requires { t + N; }` is verboten
because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103700 . For ranges::begin,
we can just decay to a pointer even in the incomplete-type case. For ranges::end,
we can safely constrain on `sizeof(*t)`. Yes, this means that an array of incomplete
type has a `ranges::begin` but no `ranges::end`... just like an unbounded array of
complete type. This is a valid manifestation of IFNDR.
All of the new libcxx/test/std/ cases are mandatory behavior, as far as I'm aware.
Tests for the IFNDR cases in ranges::begin and ranges::end remain in `libcxx/test/libcxx/`.
The similar tests for ranges::empty and ranges::data were simply wrong, AFAIK.
Differential Revision: https://reviews.llvm.org/D115838
The paths to the compiler and to the python executable may need to
be quoted (if they're installed into e.g. C:\Program Files).
All testing commands that are executed expect a gcc compatible command
line interface, while clang-cl uses different command line options.
In the original testing config, if the chosen compiler was clang-cl, it
was replaced with clang++ by looking for such an executable in the path.
For the new from-scratch test configs, I instead chose to add
"--driver-mode=g++" to flags - invoking "clang-cl --driver-mode=g++"
has the same effect as invoking "clang++", without needing to run any
heuristics for picking a different compiler executable.
Differential Revision: https://reviews.llvm.org/D111202
While there's little value in polishing the old config system,
I ran into this function and was confused for a while, while grepping
around and trying to wrap my head around things.
Differential Revision: https://reviews.llvm.org/D116131
The test is currently marked XFAIL for mingw environments, but latest
mingw-w64 got support for timespec_get:
e62a0a987c
The CI environment will probably be upgraded to a state where this
test is passing only after 14.x is branched in the llvm-project monorepo.
If we'd just go from having an XFAIL to no marking at all (when CI is
passing), we'd have to update both main and 14.x branches in sync
exactly when the CI runners are updated to a newer version.
Instead, mark the test as temporarily unsupported (so it doesn't
cause failed builds when the CI environment is updated); after the
CI environments are upgraded to such a state, we can remove the
UNSUPPORTED marking to start requiring it to pass on the main branch,
without needing to synchronize that change to anything else.
Differential Revision: https://reviews.llvm.org/D116132
Eliminate a bogus operator== overload.
Also, check more intermediate steps in the logic we're checking here.
Some of this simplification is possible only now that we've implemented
more of <ranges>.
Differential Revision: https://reviews.llvm.org/D116002
If %{exec} sets "--env PATH=single-dir", the directory containing
bash and related shell utils is omitted from the path, which means
that most shell scripts would fail.
(Setting PATH is needed for DLL builds on Windows; PATH fills the same
role as e.g. LD_LIBRARY_PATH on Linux.)
This condition is missed in the current test, because the executor
run.py first resolves the executable to run using the original path,
then invokes that executable with an environment with a restricted
path. Thus the executor is able to run bash, but that bash is then
unable to run further shell commands (other than bash builtins).
Extend the test from "bash --version" to "bash -c 'bash --version'".
This correctly identifies the executor-has-no-bash condition in the
current Windows CI configs, allowing removing 6 cases of
LIBCXX-WINDOWS-FIXME.
Another longterm fix would be to extend run.py with an option like
"--env-prepend PATH=dir", to allow keeping the current path while
adding a directory to it.
Differential Revision: https://reviews.llvm.org/D116117
This is similar to the existing setting LIBCXX_ABI_DEFINES, with
the difference that this also allows setting other defines than
ones that start with "_LIBCPP_ABI_", and allows setting defines
to a specific value.
This allows avoiding using LIBCXX_TEST_COMPILER_FLAGS in two
CI configurations.
Differential Revision: https://reviews.llvm.org/D116109
This allows cross-testing (by setting LIBCXX_EXECUTOR to point
to ssh.py) without making an entirely new test config file.
Implicitly, this also fixes quoting of the python executable name
(which is quoted in test/CMakeLists.txt).
Differential Revision: https://reviews.llvm.org/D115398
We can't just memoize _supportsVerify in place in format.py, as it
previously was executed in each of the individual processes.
Instead use hasCompileFlag() and add a feature flag for it instead,
which can be used both by tests (that already have such a flag,
locally for one set of tests) and for the testing framework itself.
By using hasCompileFlag(), this also implicitly fixes two other issues:
Previously, _supportsVerify called subprocess.call() directly, which can
interpret command line quoting differently than lit.TestRunner.
(In particular, TestRunner handles arguments quoted by a single quote,
while launching Windows processes with subprocess.call() only supports
double quotes. This allows using shlex.quote(), which uses single quotes,
everywhere - as all commands now go through TestRunner. This should make
41d7909368 redundant.)
Secondly, the old _supportsVerify method didn't include %{flags) or
%{compile_flags}.
Differential Revision: https://reviews.llvm.org/D116010
Add test for various customization point object properties as defined by
the Standard. Test various CPOs from `<ranges>`, `<iterator>`,
`<concepts>`, etc.
The test is mostly from https://reviews.llvm.org/D107036 and split up
into this.
Differential Revision: https://reviews.llvm.org/D115588
Allow `__move_constexpr` to work with unrelated pointers and `_LIBCPP_ASSERT` that `__copy_constexpr`, `__move_constexpr` and `__assign_constexpr` are only run during constant evaluation
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D115986
When P0883R2 was initially implemented in D103769 #pragma clang deprecated didn't exist yet.
We also forgot to cleanup usages in libc++ itself.
This takes care of both.
Differential Revision: https://reviews.llvm.org/D115995
__transaction is a helper class that allows rolling back code in case an
exception is thrown. The main goal is to reduce the clutter when code
needs to be guarded with `#if _LIBCPP_NO_EXCEPTIONS`.
Differential Revision: https://reviews.llvm.org/D115730
Joe Loser