Also remove some bogus `std::forward`s. My impression is that these
forwards were actually harmless, because `ranges::begin(FWD(t))` is
always identical to `ranges::begin(t)` (except when it's ill-formed,
and that can't happen in this case). However, they're also superfluous
and don't reflect the wording in the standard, so let's eliminate them.
Differential Revision: https://reviews.llvm.org/D117043
On Apple platforms, arc4random is faster than /dev/urandom, and it is
the recommended user-space RNG according to Apple's own OS folks.
This commit adds an ABI switch to guard ABI-break-protections in
std::random_device, and starts using arc4random instead of /dev/urandom
to implement std::random_device on Apple platforms.
Note that previously, `std::random_device` would allow passing a custom
token to its constructor, and that token would be interpreted as the name
of a file to read entropy from. This was implementation-defined and
undocumented. After this change, Apple platforms will be using arc4random()
instead, and any custom token passed to the constructor will be ignored.
This behavioral change will also impact other platforms that use the
arc4random() implementation, such as OpenBSD. This should be fine since
that is effectively a relaxation of the constructor's requirements.
rdar://86638350
Differential Revision: https://reviews.llvm.org/D116045
This needs a proper solution in a follow-up. The issue is that the
Standard defines conversions between `in_out_result` classes with
different template types as just `return {in, out};`. Because the
expression uses list initialization, it will fail to compile if the
conversion happens to be narrowing -- which is probably unintended.
Surprisingly, this error wasn't caught by the CI.
Differential Revision: https://reviews.llvm.org/D117089
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
... 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.
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
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
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
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
`__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
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
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
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
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 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
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
Also:
- refactor out `__voidify`;
- use the `destroy` algorithm internally;
- refactor out helper classes used in tests for `uninitialized_*`
algorithms.
Differential Revision: https://reviews.llvm.org/D115626
There is no need to check the counters on `Counted` after destroying
elements in the range because these tests are not testing `destroy`.
Differential Revision: https://reviews.llvm.org/D115839
Remove `s.base()`; every test that wants to get the base of a "test sentinel"
should use the ADL `base(s)` from now on.
Differential Revision: https://reviews.llvm.org/D115766
GCC currently does not allow `__builtin_strlen()` during constant evaluation. This PR adds a workaround in `std::char_traits<char>::length()`
Reviewed By: Quuxplusone, ldionne, #libc, Mordante
Spies: Mordante, libcxx-commits
Differential Revision: https://reviews.llvm.org/D115795
Defined in [`specialized.algorithms`](wg21.link/specialized.algorithms).
Also:
- refactor the existing non-range implementation so that most of it
can be shared between the range-based and non-range-based algorithms;
- remove an existing test for the non-range version of
`uninitialized_default_construct{,_n}` that likely triggered undefined
behavior (it read the values of built-ins after default-initializing
them, essentially reading uninitialized memory).
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D115315
A few tests in the test suite require support for Bash. For example,
tests that run a program and send data through stdin to it require some
way of piping the data in, and we use a Bash script for that.
However, some executors (e.g. an embedded systems simulator) do not
support Bash, so these tests will fail. This commit adds a Lit feature
that tries to detect whether Bash is available through conventional
means, and disables the tests that require it otherwise.
Differential Revision: https://reviews.llvm.org/D114612
As explained in https://stackoverflow.com/a/70339311/627587, the fact
that shrink_to_fit wasn't defined as inline lead to issues when explicitly
instantiating basic_string. While explicit instantiations are always
somewhat brittle, this one was clearly a bug on our end.
Differential Revision: https://reviews.llvm.org/D115656
When `a` was an array type, `__decay_copy(a)` was incorrectly marking itself
noexcept(false), because it is false that `int[10]` is nothrow convertible to `int[10]`
(in fact it is not convertible at all).
We have no tests explicitly for `__decay_copy`, but the new ranges::begin
and ranges::end tests fail before this patch.
Differential Revision: https://reviews.llvm.org/D115658
The aim of this patch is to fix the post processing that is happening on the temporary test directories upon scope exit. In particular, ~scoped_test_env aims to chmod and remove the temporary directories; however,
bad symlinks are followed and we get "No such file or directory". FIX: use find as alternative to chmod and avoid -follow option.
Attempting to remove read-only files on z/OS prompts a message asking for confirmation. FIX: use the -f option to delete read-only files immediately without asking for confirmation.
Some libcxx tests such as libcxx/test/std/input.output/filesystems/cl ass.directory_entry/directory_entry.cons/path.pass.cpp set the dir permissions to none. In turn, recursively doing chmod (-R) does not set the file permissions needed to be able to remove the dir on z/OS only. FIX: use find as alternative to chmod -R, which does not run into this issue on z/OS.
Differential Revision: https://reviews.llvm.org/D108326
Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ryu Printf algorithms invented by Ulf Adams at Google. Upstream repos: https://github.com/microsoft/STL and https://github.com/ulfjack/ryu .
Licensing notes: MSVC's STL is available under the Apache License v2.0 with LLVM Exception, intentionally chosen to match libc++. We've used Ryu under the Boost Software License.
This patch contains minor changes from Jorg Brown at Google, to adapt the code to libc++. He verified that it works in Google's Linux-based environment, but then I applied more changes on top of his, so any compiler errors are my fault. (I haven't tried to build and test libc++ yet.) Please tell me if we need to do anything else in order to follow https://llvm.org/docs/DeveloperPolicy.html#attribution-of-changes .
Notes:
* libc++'s integer charconv is unchanged (except for a small refactoring). MSVC's integer charconv hasn't been tuned for performance yet, so you're not missing anything.
* Floating-point from_chars isn't part of this patch because Jorg found that MSVC's implementation (derived from our CRT's strtod) was slower than Abseil's. If you're unable to use Abseil or another implementation due to licensing or technical considerations, Microsoft would be delighted if you used MSVC's from_chars (and you can just take it, or ask us to provide a patch like this). Ulf is also working on a novel algorithm for from_chars.
* This assumes that float is IEEE 32-bit, double is IEEE 64-bit, and long double is also IEEE 64-bit.
* I have added MSVC's charconv tests (the whole thing: integer/floating from_chars/to_chars), but haven't adapted them to libcxx's harness at all. (These tests will be available in the microsoft/STL repo soon.)
* Jorg added int128 codepaths. These were originally present in upstream Ryu, and I removed them from microsoft/STL purely for performance reasons (MSVC doesn't support int128; Clang on Windows does, but I found that x64 intrinsics were slightly faster).
* The implementation is split into 3 headers. In MSVC's STL, charconv contains only Microsoft-written code. xcharconv_ryu.h contains code derived from Ryu (with significant modifications and additions). xcharconv_ryu_tables.h contains Ryu's large lookup tables (they were sufficiently large to make editing inconvenient, hence the separate file). The xmeow.h convention is MSVC's for internal headers; you may wish to rename them.
* You should consider separately compiling the lookup tables (see https://github.com/microsoft/STL/issues/172 ) for compiler throughput and reduced object file size.
* See https://github.com/StephanTLavavej/llvm-project/commits/charconv for fine-grained history. (If necessary, I can perform some rebase surgery to show you what Jorg changed relative to the microsoft/STL repo; currently that's all fused into the first commit.)
Differential Revision: https://reviews.llvm.org/D70631
Test that `nothrow-forward-iterator` subsumes `nothrow-input-iterator`,
`nothrow-forward-range` subsumes `nothrow-input-range`, and
`nothrow-sentinel-for` and `sentinel_for` subsume each other.
This is a follow-up to [D114761](https://reviews.llvm.org/D114761).
Differential Revision: https://reviews.llvm.org/D115422
Extending std::vector tests in vector.cons module:
- std::vector::assign when source range is bigger than destination
capacity
- construction of empty vector using copy ctor, initializer_list ctor and
others
Reviewed By: ldionne, rarutyun, #libc
Differential Revision: https://reviews.llvm.org/D114954
Add tests for std::set and std::multiset comparisons that were missed by
D111738 and D112424.
Reviewed By: ldionne, rarutyun, #libc
Differential Revision: https://reviews.llvm.org/D115136
No decrease in test coverage intended. The original goal here
was just to get rid of the global name `sentinel` so that we can
rename the `sentinel_wrapper` in "test_iterators.h" to `sentinel`;
but then I took a closer look at the offending tests and saw
that some of them probably weren't testing what they intended.
Also, add one `/*explicit*/` and one #if'ed out test indicating
bugs in the current ranges::empty (to be fixed by D115312 or
some equivalent patch).
Reviewed as part of D115272.
This follows up on my addition of base(cpp20_input_iterator) in D115177,
making all the ADL base() functions consistent.
Also align cpp20_input_iterator with the other test iterators' style.
Reviewed as part of D115272.
There's a lot of history behind this, so here's a summary:
1. I stopped forcing -fPIC when building the runtimes in 30f305efe2,
before the LLVM 9 release back in 2019.
2. Someone complained that libc++.a couldn't be used in shared libraries
built without -fPIC (http://llvm.org/PR43604) since the LLVM 9 release.
This had been caused by my removal of -fPIC when building libc++.a in (1).
3. I suggested two ways of fixing the issue, the first being to force
-fPIC back unconditionally (http://llvm.org/D104328), and the second
being to specify that option explicitly when building the LLVM release
(http://llvm.org/D104327). We converged on the first solution.
4. I landed D104328, which forced building the runtimes with -fPIC.
This was included in the LLVM 13.0 release.
5. People complained about that and requested that we be able to
customize this setting (basically we should have done the second
solution).
This patch makes it such that the LLVM release script will specifically
ask for building with -fPIC using CMAKE_POSITION_INDEPENDENT_CODE,
however by default the runtimes will not force that option onto users.
This patch has the unintended effect that Clang and the LLVM libraries
(not only the runtime ones like libc++) will also be built with -fPIC
in the release. It would be better if we could specify that -fPIC is to
be used only when building the runtimes, however this is left as a
future improvement. The release should probably be using a bootstrapping
build and passing those options to the stage that builds the runtimes
only, see https://reviews.llvm.org/D112748 for that change.
Differential Revision: https://reviews.llvm.org/D110261
In addition to being more consistent with our approach for helpers, this
solves an actual issue where <cmath> was using numeric_limits but never
including the <limits> header directly. In a normal setup, this is not
an issue because the <math.h> header included by <cmath> does include
<limits>. However, I did stumble upon some code where that didn't work,
most likely because they were placing their own <math.h> header in front
of ours. I didn't bother investigating further.
Differential Revision: https://reviews.llvm.org/D115282
Before this patch, the new test's `CountedInvocable<int*, int*>`
would hard-error instead of SFINAEing and cleanly returning false.
Notice that views::counted specifically does NOT work with pipes;
`counted(42)` is ill-formed. This is because `counted`'s first argument
is supposed to be an iterator, not a range.
Also, mark `views::counted(it, n)` as [[nodiscard]], and test that.
(We have a general policy now that range adaptors are consistently
marked [[nodiscard]], so that people don't accidentally think that
they have side effects. This matters mostly for `reverse` and
`transform`, arguably `drop`, and just generally let's be consistent.)
Differential Revision: https://reviews.llvm.org/D115177
In 6c75ab5f66, Clang deprecated _ExtInt in favor of _BitInt, which
made this test fail. This patch disables the test on older compilers
and uses the new _BitInt type instead.
Differential Revision: https://reviews.llvm.org/D115194
I assume nobody ever uses std::string_view::max_size() outside of
testing. However, we should still return a value that is based on
something with a reasonable rationale. Previously, we would forget
to take into account the size of the character type stored in the
string, and this patch takes that into account.
Thanks to @mclow.lists for pointing out this issue.
Differential Revision: https://reviews.llvm.org/D114395
Clang trunk rejects the new test case, but this is a Clang bug
(PR47414, 47509, 50864, 44833).
```
In module 'std' imported from /Users/aodwyer/llvm-project/libcxx/test/std/ranges/range.adaptors/range.transform/general.pass.cpp:17:
/Users/aodwyer/llvm-project/build2/include/c++/v1/__ranges/transform_view.h:85:44: error: constraints not satisfied for alias template 'range_reference_t' [with _Rp = const NonConstView]
regular_invocable<const _Fn&, range_reference_t<const _View>>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/aodwyer/llvm-project/build2/include/c++/v1/__ranges/transform_view.h:416:25: note: in instantiation of template class 'std::ranges::transform_view<NonConstView, (lambda at /Users/aodwyer/llvm-project/libcxx/test/std/ranges/range.adaptors/range.transform/general.pass.cpp:73:71)>' requested here
-> decltype( transform_view(_VSTD::forward<_Range>(__range), _VSTD::forward<_Fn>(__f)))
^
```
We can work around this by adding a layer of indirection: put the
problematic constraint into a named concept and Clang becomes more
amenable to SFINAE'ing instead of hard-erroring.
Drive-by simplify `range.transform/general.pass.cpp` to make it clearer
what it's actually testing in this area.
Differential Revision: https://reviews.llvm.org/D115116
Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ryu Printf algorithms invented by Ulf Adams at Google. Upstream repos: https://github.com/microsoft/STL and https://github.com/ulfjack/ryu .
Licensing notes: MSVC's STL is available under the Apache License v2.0 with LLVM Exception, intentionally chosen to match libc++. We've used Ryu under the Boost Software License.
This patch contains minor changes from Jorg Brown at Google, to adapt the code to libc++. He verified that it works in Google's Linux-based environment, but then I applied more changes on top of his, so any compiler errors are my fault. (I haven't tried to build and test libc++ yet.) Please tell me if we need to do anything else in order to follow https://llvm.org/docs/DeveloperPolicy.html#attribution-of-changes .
Notes:
* libc++'s integer charconv is unchanged (except for a small refactoring). MSVC's integer charconv hasn't been tuned for performance yet, so you're not missing anything.
* Floating-point from_chars isn't part of this patch because Jorg found that MSVC's implementation (derived from our CRT's strtod) was slower than Abseil's. If you're unable to use Abseil or another implementation due to licensing or technical considerations, Microsoft would be delighted if you used MSVC's from_chars (and you can just take it, or ask us to provide a patch like this). Ulf is also working on a novel algorithm for from_chars.
* This assumes that float is IEEE 32-bit, double is IEEE 64-bit, and long double is also IEEE 64-bit.
* I have added MSVC's charconv tests (the whole thing: integer/floating from_chars/to_chars), but haven't adapted them to libcxx's harness at all. (These tests will be available in the microsoft/STL repo soon.)
* Jorg added int128 codepaths. These were originally present in upstream Ryu, and I removed them from microsoft/STL purely for performance reasons (MSVC doesn't support int128; Clang on Windows does, but I found that x64 intrinsics were slightly faster).
* The implementation is split into 3 headers. In MSVC's STL, charconv contains only Microsoft-written code. xcharconv_ryu.h contains code derived from Ryu (with significant modifications and additions). xcharconv_ryu_tables.h contains Ryu's large lookup tables (they were sufficiently large to make editing inconvenient, hence the separate file). The xmeow.h convention is MSVC's for internal headers; you may wish to rename them.
* You should consider separately compiling the lookup tables (see https://github.com/microsoft/STL/issues/172 ) for compiler throughput and reduced object file size.
* See https://github.com/StephanTLavavej/llvm-project/commits/charconv for fine-grained history. (If necessary, I can perform some rebase surgery to show you what Jorg changed relative to the microsoft/STL repo; currently that's all fused into the first commit.)
Differential Revision: https://reviews.llvm.org/D70631
Implement the exposition-only concepts specified in
`[special.mem.concepts]`. These are all thin wrappers over other
concepts.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D114761
Seems better to rely on the existing formatting, makes the output
smaller/simpler - this is consistent with libstdc++'s std::string_view
pretty printing too.
Differential Revision: https://reviews.llvm.org/D113244
Implement P1989R2 which adds a range constructor for `string_view`.
Adjust `operator/=` in `path` to avoid atomic constraints caching issue
getting provoked from this PR.
Add defaulted template argument to `string_view`'s "sufficient
overloads" to avoid mangling issues in `clang-cl` builds. It is a
MSVC mangling bug that this works around.
Differential Revision: https://reviews.llvm.org/D113161
Add missing tests for std::vector funcionality to improve code coverage:
- Rewrote access tests to check modification of the container using
the reference returned by the non-const overload
- Added tests for reverse iterators: rbegin, rend, etc.
- Added exception test for vector::reserve
- Extended test cases for vector copy assignment
- Fixed insert_iter_value.pass.cpp to use insert overload with const
value_type& (not with value_type&& which is tested in
iter_rvalue.pass.cpp test)
Reviewed By: Quuxplusone, rarutyun, #libc
Differential Revision: https://reviews.llvm.org/D112438
Reviewed as part of D114658.
Ultimately this will probably have to be flipped around and renamed
`TEST_IS_RUNTIME`, and extended with `TEST_IS_RUNTIME_OR_CXX20` (once
constexpr std::string support is added) and so on for every new C++
version. But we don't need that flexibility yet, so we're not adding it.
Disable the constructors taking `(size_type, const value_type&,
allocator_type)` if `allocator_type` is not a valid allocator.
Otherwise, these constructors are considered when resolving e.g.
`(int*, int*, NotAnAllocator())`, leading to a hard error during
instantiation. A hard error makes the Standard's requirement to not
consider deduction guides of the form `(Iterator, Iterator,
BadAllocator)` during overload resolution essentially non-functional.
The previous approach was to SFINAE away `allocator_traits`. This patch
SFINAEs away the specific constructors instead, for consistency with
`basic_string` -- see [LWG3076](wg21.link/lwg3076) which describes
a very similar problem for strings (note, however, that unlike LWG3076,
no valid constructor call is affected by the bad instantiation).
Differential Revision: https://reviews.llvm.org/D114311
This patch removes the ability to build the runtimes in the 32 bit
multilib configuration, i.e. using -m32. Instead of doing this, one
should cross-compile the runtimes for the appropriate target triple,
like we do for all other triples.
As it stands, -m32 has several issues, which all seem to be related to
the fact that it's not well supported by the operating systems that
libc++ support. The simplest path towards fixing this is to remove
support for the configuration, which is also the best course of action
if there is little interest for keeping that configuration. If there
is a desire to keep this configuration around, we'll need to do some
work to figure out the underlying issues and fix them.
Differential Revision: https://reviews.llvm.org/D114473
This removes the `format_args_t` from `<format>` and adjusts the type of
the `format_args` for the `vformat_to` overloads.
The `format_context` uses a `back_insert_iterator<string>` therefore the
new `output_iterator` function uses a `string` as its temporary storage
buffer. This isn't ideal. The next patches in this series will improve
this. These improvements make it easy to also improve `format_to_n` and
`formatted_size`.
This addresses P2216 `6. Binary size`.
P2216 `5. Compile-time checks` are not part of this change.
Implements parts of:
- P2216 std::format improvements
Depends on D103670
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D110494
Fixes https://llvm.org/PR51520. The problem is that `uniform_int_distribution`
currently uses an unsigned integer with at most 64 bits internally, which
is then casted to the desired result type. If the result type is `int64_t`,
this will produce a negative number if the most significant bit is set,
but if the result type is `__int128_t`, the value remains non-negative
and will be out of bounds for the example in PR#51520. (The reason why
it also seems to work if the upper or lower bound is changed is
because the branch at [1] will then no longer be taken, and proper
rejection sampling takes place.)
The bigger issue here is probably that `uniform_int_distribution` can be
instantiated with `__int128_t` but will silently produce incorrect results
(only the lowest 64 bits can ever be set). libstdc++ also supports `__int128_t`
as a result type, so I have simply extended the maximum width of the
internal intermediate result type.
[1]: https://github.com/llvm/llvm-project/blob/6d28dffb6/libcxx/include/__random/uniform_int_distribution.h#L266-L267
Differential Revision: https://reviews.llvm.org/D114129
The test doesn't depend specifically on the en_US.UTF-8 locale, instead
it depends on whether localization support exists, period.
Differential Revision: https://reviews.llvm.org/D114708
Add missing tests to improve associative containers code coverage:
- Tests for key_comp() and value_comp() observers
- Tests for std::map and std::multimap value_compare member class
Reviewed by: ldionne, rarutyun, #libc
Differential Revision: https://reviews.llvm.org/D113998
Instead of silently swallowing errors that happen during Lit configuration
(for example trying to obtain compiler macros but compiling fails), raise
an exception with some amount of helpful information.
This should avoid the possibility of silently configuring Lit in a bogus
way, and also provides more helpful information when things fail.
Note that this requires a bit more finesse around how we handle some
failing configuration checks that we would previously return None for.
Differential Revision: https://reviews.llvm.org/D114010
This patch implements operator<=> for std::reverse_iterator and
also adds a test that checks that three-way comparison of different
instantiations of std::reverse_iterator works as expected (related to
D113417).
Reviewed By: ldionne, Quuxplusone, #libc
Differential Revision: https://reviews.llvm.org/D113695
On some platforms like armv7m, the size() method of containers returns
unsigned long, while ptrdiff_t is just int. Hence, std::ssize_t ends up
being long, which is not the same as ptrdiff_t. This is usually not an
issue because std::ptrdiff_t is long, so everything works out, but it
breaks on some more exotic architectures.
Differential Revision: https://reviews.llvm.org/D114563
According to the C++ standard, the stored pointer and the stored deleter
should be value-initialized.
Differential Revision: https://reviews.llvm.org/D113612
In 1fa27f2a10, we made <filesystem>'s iterator types model concepts
from <ranges>, but we forgot to add the appropriate availability
annotations. This broke back-deployment to platforms that don't have
<filesystem> for which we have availability annotations.
For some reason, this wasn't caught by our back-deployment CI.
I believe this is due to the fact that we use a slightly older
compiler in the CI, and perhaps that compiler does not honour
our `#pragma clang attribute push` properly.
Differential Revision: https://reviews.llvm.org/D114456
This does not include `std::compare_*_fallback`; those are coming later.
There's still an open question of how to implement std::strong_order
for `long double`, which has 80 value bits and 48 padding bits on x86-64,
and which is presumably *not* IEEE 754-compliant on PPC64 and so on.
So that part is left unimplemented.
Differential Revision: https://reviews.llvm.org/D110738
Actually there's one functional change here, which is that users can
no longer depend on <random> to include all of C++20 <concepts>. That
inclusion is so new that we believe nobody should be depending on it
yet, even in the presence of Hyrum's Law. We keep the includes of <vector>,
<algorithm>, etc., so as not to break pre-C++20 Hyrum's Law users.
Differential Revision: https://reviews.llvm.org/D114281
In the test suite, we generally don't use printf or other reporting
utilities. It's not that it wouldn't be useful, it's just that some
platforms don't support IO.
Instead, we try to keep test cases small and self-contained so that
we can reasonably easily reproduce failures locally and debug them.
This patch removes printf in some of the last places in the test suite
that used it. The only remaining places are in a deque test and in the
filesystem tests. The filesystem tests are arguably fine to keep using
IO, since we're testing <filesystem>. The deque test will be handled
separately.
Differential Revision: https://reviews.llvm.org/D114282
At this point, every supported compiler that claims a -std=c++17 mode
should also support these features.
Differential Revision: https://reviews.llvm.org/D113436
This is not mandated by the standard, so it goes in libcxx/test/libcxx/.
It's certainly arguable that the algorithms changed here
(`is_heap`, `is_sorted`, `min`, `max`) are harmless and we should
just let them copy their comparators once. But at the same time,
it's nice to have all our algorithms be 100% consistent and never
copy a comparator, not even once.
Differential Revision: https://reviews.llvm.org/D114136
We would have been defining it in <utility> instead of <charconv>. For
the time being, this doesn't change anything since we don't implement
the feature test macro anyways.
Also, as a fly-by, this removes obsolete feature test macro tests. There
was a brief time back in the days when we wrote feature test macro tests
manually. In particular, we had test files for __cpp_lib_to_chars and
__cpp_lib_memory_resource. Since we now have a principled way of generating
these tests with scripts, this commit removes the obsolete (and empty)
tests for these two feature test macros.
Differential Revision: https://reviews.llvm.org/D114243
We never noticed it because our CI doesn't actually build against a C
library that doesn't have threading functionality, however building
against a truly thread-free platform surfaces these issues.
Differential Revision: https://reviews.llvm.org/D114242
One some platforms, -Wimplicit-int-conversion is enabled by default,
which can lead to additional warnings being triggered in this test.
Since we're only trying to test errors related to calling abs(), the
assignment is superfluous.
As a fly-by fix, correct one instance of ::abs to std::abs and made
the test a .verify.cpp test instead.
Differential Revision: https://reviews.llvm.org/D114244
This patch resolves many of the failures in the `filesystems/` buckets in the libc++ tests. It adds the correct flag to `fopen` and marks a test case as unsupported. In particular, that test assumes time is stored as a 64 bit value when on MVS it is stored as 32 bit.
Differential Revision: https://reviews.llvm.org/D113298
The aim of this patch is to resolve the missing `table_size` symbol (see reduced test case). That const variable is declared and defined in //libcxx/include/locale//; however, the test case suggests that the symbol is missing. This is due to a C++ pitfall (highlighted [[ https://quuxplusone.github.io/blog/2020/09/19/value-or-pitfall/ | here ]]). In summary, assigning the reference of `table_size` doesn't enforce the const-ness and expects to find `table_size` in the DLL. The fix is to use `constexpr` or have an out-of-line definition in the src (for consistency).
Differential Revision: https://reviews.llvm.org/D110647
Also, mark these tests as compile-only. They actually are safe to run — notice that
the code "runs" at constexpr-time in C++20, without error — because both of the
input ranges are entirely filled with nullptr, so no matter how you shuffle the
elements, they remain sorted and partitioned and heapified and everything.
But there's no real reason to run them at runtime, so let's just avoid the distraction.
Test cases that fail in trunk right now are commented out with `TODO FIXME`.
Differential Revision: https://reviews.llvm.org/D113906
std::atomic is, for the most part, just a thin veneer on top of compiler
builtins. Hence, it should be available even when threads are not available
on the system, and in fact there has been requests for such support.
This patch:
- Moves __libcpp_thread_poll_with_backoff to its own header so it can
be used in <atomic> when threads are disabled.
- Adds a dummy backoff policy for atomic polling that doesn't know about
threads.
- Adjusts the <atomic> feature-test macros so they are provided even when
threads are disabled.
- Runs the <atomic> tests when threads are disabled.
rdar://77873569
Differential Revision: https://reviews.llvm.org/D114109
Since we've decided the to not support std::experimental::coroutine*, we
should tell the user they need to update.
Reviewed By: Quuxplusone, ldionne, Mordante
Differential Revision: https://reviews.llvm.org/D113977
- Replace irrelevant synopsis by a comment
- Use a .verify.cpp test instead of .compile.fail.cpp
- Remove unnecessary includes in one of the tests (was a copy-paste error)
Differential Revision: https://reviews.llvm.org/D114094
Mention support for MinGW in the docs. Rename the existing windows
CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much
"Windows", just different toolchain environments.
Add an XFAIL for a recently added test that fails in the MinGW DLL
configuration (with an explanation of what's causing the failure).
Differential Revision: https://reviews.llvm.org/D112215
This effort is dedicated to deflake the tests of the users which depend
on the unspecified behavior of algorithms and containers. This also
might help updating the sorting algorithm in libcxx which has the
quadratic worst case in the future or at least create a new one under
flag.
For detailed design, please see the design doc I provide in the patch.
Differential Revision: https://reviews.llvm.org/D96946
However, whether applications rely on the std::bad_function_call vtable
being in the dylib is still controlled by the ABI macro, since changing
that would be an ABI break.
Also separate preprocessor definitions for whether to use a key function
and whether to use a `bad_function_call`-specific `what` message
(`what` message is mandated by [LWG2233](http://wg21.link/LWG2233)).
Differential Revision: https://reviews.llvm.org/D92397
Places `format_to_n_result` to its own file. While working on D112361 it
turns out the type will be used outside the format header.
Reviewed By: #libc, Quuxplusone, Mordante
Differential Revision: https://reviews.llvm.org/D113831
Since coroutine is merged in C++ standard and the support for coroutine
seems relatively stable. It's the time to move the implementation of
coroutine out of the experimental directory and the std::experimental
namespace. This patch creates header <coroutine> with conformed
implementation with C++ standard. To avoid breaking user's code too
fast, the <experimental/coroutine> header is remained. Note that
<experimental/coroutine> is deprecated and it would be removed in
LLVM15.
Reviewed By: Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D109433
This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.
As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D110216
The template std::is_assignable<T, U> checks that T is assignable from
U. Hence, the order of operands in the instantiation of
std::is_assignable in the std::reverse_iterator::operator= condition
should be reversed.
This issue remained unnoticed because std::reverse_iterator has an
implicit conversion constructor. This patch adds a test to check that
the assignment operator is used directly, without any implicit
conversions. The patch also adds a similar test for
std::move_iterator.
Reviewed By: Quuxplusone, ldionne, #libc
Differential Revision: https://reviews.llvm.org/D113417
This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.
As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D110216
We missed the tests in the earlier XFAIL-ing because the locale.fr_FR.UTF-8
feature wasn't available, but since an upgrade these are now showing up
on the CI.
Differential Revision: https://reviews.llvm.org/D113791
This addresses the usage of `operator&` in `<list>`.
(Note there are still more headers with the same issue.)
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D112654
Arthur O'Dwyer