`<filesystem>` header has been around for a while now, so we can safely remove
`<experimental/filesystem>` header. `_LIBCPP_DEPRECATED_EXPERIMENTAL_FILESYSTEM`
suggests we were going to remove `<experimental/filesystem>` in llvm 11 release,
but we never did. So, remove the experimental header now, its associated tests,
and the `_LIBCPP_DEPRECATED_EXPERIMENTAL_FILESYSTEM` macro.
Differential Revision: https://reviews.llvm.org/D119603
- add some test cases for `cbegin`/`cend`;
- make class definitions generally follow the order in which they are
used;
- add a missing include.
Reviewed By: philnik
Differential Revision: https://reviews.llvm.org/D119214
This avoids using an libc++ internal macro in our tests. This version
doesn't depend on the internal macro but redefines it.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D119460
b07b5bd727 adds a use of `__comp_ref_type.h` to `std::min`. When libc++ is built with `-D_LIBCPP_DEBUG=0`, this enables `std::__debug_less`, which is only marked constexpr after c++17.
`std::min` itself is marked as being `constexpr` as of c++14, so by extension, `std::__debug_less` should also be marked `constexpr` for the same versions so that `std::min` can use it. This change lowers the guard from `> 17` to `> 11`.
Reproducer in godbolt: https://godbolt.org/z/ans3TGsj8
```
constexpr int x() { return std::min<int>({1, 2, 3, 4}); }
static_assert(x() == 1);
```
Reviewed By: #libc, philnik, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D118940
Glibc adds a +-sign for NaN-values when showpos fmtflags are set.
[tab:ios.fmtflags]
showpos generates a + sign in non-negative generated numeric output
Since NaNs aren't negative this behaviour seems correct. Enable the test
for glibc and add ifdefs to make sure the existing tests still pass.
This was noticed while working on D118971.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D119260
Previously, _LIBCPP_ABI_UNSTABLE would be used interchangeably with
_LIBCPP_ABI_VERSION >= 2. This was confusing and creating unnecessary
complexity.
This patch removes _LIBCPP_ABI_UNSTABLE -- instead, the LIBCXX_ABI_UNSTABLE
CMake option will result in the LIBCXX_ABI_VERSION being set to '2', the
current unstable ABI. As a result, in the code, we only have _LIBCPP_ABI_VERSION
to check in order to query the current ABI version.
As a fly-by, this also defines the ABI namespace during CMake configuration
to reduce complexity in __config. I believe it was previously done this
way because we used to try to use __config_site as seldom as possible.
Now that we always ship a __config_site, it doesn't really matter and
I think being explicit about how the library is configured in the __config_site
is actually a feature.
Differential Revision: https://reviews.llvm.org/D119173
This change is a preparation for adapting the tests for
P2216 std::format improvements
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D118717
This testing configuration links tests against one libc++ shared library,
but runs them against another libc++ shared library. This makes sure that
we can build applications against the libc++ provided in a recent SDK and
back-deploy them to platforms containing older libc++ dylibs.
It also switches the Apple CI script to using that new configuration
instead of the legacy one.
Differential Revision: https://reviews.llvm.org/D119195
Back in https://reviews.llvm.org/D109459, we stopped using the C++03
emulation for std::nullptr_t by default, which was an ABI break. We
still left a knob for users to turn it back on if they were broken by
the change, with a note that we would remove that knob after one release.
The time has now come to remove the knob and clean up the std::nullptr_t
emulation.
Differential Revision: https://reviews.llvm.org/D114786
containers
Add test cases for iteration over the ordered associative container from
end to begin using operator--
Reviewed By: Quuxplusone, rarutyun
Differential Revision: https://reviews.llvm.org/D118114
var-const points out that `ranges::begin` is (non-normatively
but explicitly) always supposed to return a `std::input_or_output_iterator`,
and `Incomplete*` is not a `std::input_or_output_iterator` because it
has no `operator++`. Therefore, we should never return `Incomplete*`
from `ranges::begin(x)`, even when `x` is `Incomplete(&)[]`. Instead,
just SFINAE away.
Differential Revision: https://reviews.llvm.org/D118963
For some reason `<string>` defines `std::fpos`, which should be defined in `<ios>`.
Reviewed By: Quuxplusone, Mordante, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D118914
Discovered in the comments on D118748: we would like this namespace
to exist anytime Ranges exists, regardless of whether concepts syntax
is supported. Also, we'd like to fully granularize the <ranges> header,
which means not putting any loose declarations at the top level.
Differential Revision: https://reviews.llvm.org/D118809
The renames the output_iterator to cpp17_output_iterator. These
iterators are still used in C++20 so it's not possible to change the
current type to the new C++20 requirements. This is done in a similar
fashion as the cpp17_input_iterator.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D117950
As per [time.duration.cons]/1, the constructor constraint should be on
const Rep2&. As it is now the code will fail to compile in certain
cases, for example (https://godbolt.org/z/c7fPrcTYM):
struct S{
operator int() const&& noexcept = delete;
operator int() const& noexcept;
};
const S &fun();
auto k = std::chrono::microseconds{fun()};
Differential Revision: https://reviews.llvm.org/D118902
Note that most changes to `strings` and `views.span` from the One Ranges
Proposal are no longer applicable:
- free `begin` and `end` functions taking `basic_string_view` and `span`
were removed by [P1870](http://wg21.link/p1870);
- `span::const_iterator` was removed by [LWG3320](https://cplusplus.github.io/LWG/lwg-defects.html#3320).
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D118687
This started breaking in the CI because we bumped the Clang version
to 15, which requires adjusting the markup in the test suite.
Differential Revision: https://reviews.llvm.org/D118838
There is no reason for the parts of std::span that don't depend on ranges
to be disabled when ranges aren't provided. Also, to make sure the
"no-experimental-stuff" configuration is tested, add a CI job for it.
Differential Revision: https://reviews.llvm.org/D118740
The old `__regex_word` aliased the mask for `xdigit`, causing stray
test failures.
The diff may look surprising, as if the previous faulty value had
been set specifically for Windows - but this is due to a restructuring
in 411c630bae. Prior to that, there
were OS specific settings for some OSes, and one fallback used for
the rest (which turns out to not work for Windows).
Differential Revision: https://reviews.llvm.org/D118188
In ancient Microsoft C runtimes, there might only have been
a nonstandard `_vsnprintf` instead of the standard `vsnprintf`, but
in modern versions (the only ones relevant for libc++), both
are available.
In MinGW configurations built with `__USE_MINGW_ANSI_STDIO=1` (as it
is built in CI), `vsnprintf` provides a more standards compliant
behaviour than what Microsoft's CRT provides, while `_vsnprintf` retains
the Microsoft C runtime specific quirks.
Differential Revision: https://reviews.llvm.org/D118187
As discovered in D117817, `std::ranges::input_range<Holder<Incomplete>*[10]>`
hard-errored before this patch. That's because `input_range` requires
`iter_rvalue_reference_t`, which requires `iter_move`, which was
not ADL-proofed.
Add ADL-proofing tests to all the range refinements.
`output_range` and `common_range` shouldn't be affected,
and all the others subsume `input_range` anyway, but we might as
well be thorough.
Differential Revision: https://reviews.llvm.org/D118213
This includes an experimental workaround for
LWG3664 "LWG3392 broke std::ranges::distance(a, a+3)",
but the workaround may be incomplete, I'm not sure.
This should be re-audited when LWG3664 is actually adopted,
to see if we need to change anything about our implementation.
See also https://github.com/microsoft/STL/pull/2500
Differential Revision: https://reviews.llvm.org/D117940
The macro that opts out of `std::ranges::` functionality is called
`_LIBCPP_HAS_NO_INCOMPLETE_RANGES`, and is unrelated to this macro
which is specifically about _compiler_ support for the _syntax_.
The only non-mechanical diff here is in `<__config>`.
Differential Revision: https://reviews.llvm.org/D118507
Remove copy and copy assignment rather than have them as private declarations.
They are superfluous given the move and move assignment.
As a drive-by, also specialize `std::hash` without reopening `namespace std`.
Differential Revision: https://reviews.llvm.org/D118502
These were omitted in all Windows configurations, but it turns out
that they work just fine in MinGW mode.
This allows converting a couple cases of "XFAIL: LIBCXX-WINDOWS-FIXME"
into "XFAIL: msvc" as the bug is specific to MSVC mode (clang-cl).
Differential Revision: https://reviews.llvm.org/D118192
The tests for these are just copy-pasted from the tests for std::{strong,weak,partial}_order,
and then I added an extra clause in each (test_2()) to test the stuff that's not just the same
as std::*_order.
This also includes the fix for https://wg21.link/LWG3465 (which falls naturally out of the
"you must write it three times" style, but I've added test cases for it also).
There is an action item here to go back and give good diagnostics for SFINAE failures
in these CPOs. I've filed this as https://github.com/llvm/llvm-project/issues/53456 .
Differential Revision: https://reviews.llvm.org/D111514
This should fix the regressions detected in D117992.
This lands before D117992 to avoid breaking main.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D118056
In `ranges::advance(iter, n, bound)`, we'd incorrectly handle the case
where bound < iter and n is 0:
int a[10];
int *p = a+5;
int *bound = a+3;
std::ranges::advance(p, 0, bound);
assert(p - a == 5); // we'd return 3 before this patch
This was caused by an incorrect handling of 0 inside __magnitude_geq.
Differential Revision: https://reviews.llvm.org/D117240
We were missing a constraint in common_iterator's iterator_traits and
we were eagerly instantiating iter_value_t even when invalid.
Thanks to Casey Carter for finding this bug.
Differential Revision: https://reviews.llvm.org/D117449
Fixed in counted_iterator and transform_view::iterator.
The LWG issue also affected elements_view::iterator, but we haven't
implemented that one yet, and whoever does implement it will get
the fix for free if they just follow the working draft's wording.
Drive-by stop calling `.base()` on test iterators in the test,
and improve the transform_view::iterator/sentinel tests.
Differential Revision: https://reviews.llvm.org/D117329
Remove a bunch of LIBCPP_CXX03_LANG. This is the result of a
rabbithole to re-eliminate the workaround I introduced into
std::cref in D117953. It turns out that Clang's C++03 mode
(the only compiler we care about C++03 for) now supports all
the things we were originally eschewing via LIBCPP_CXX03_LANG;
we can fully support these reference_wrapper features in
C++03 mode, and un-XFAIL the relevant tests.
Drive-by constexprify a few more tests.
Differential Revision: https://reviews.llvm.org/D117974
The Windows and Glibc abbreviated form of Saturday in French locale
is "sam." with a trailing period included. Account for this in the
test reference.
Differential Revision: https://reviews.llvm.org/D118240
This allows getting rid of one case of LIBCXX-WINDOWS-FIXME. The fixme
comment was inaccurate; aligned allocation functions are provided these
days, but the test kept failing as it was using mismatched allocation
and free functions.
A similar issue was fixed earlier, in
6596778b46. That test was fixed by
overriding the aligned `operator new` too, and returning a dummy fixed
allocation instead. As this test is libcxx specific, it can use the
internal `std::__libcpp_aligned_free()` instead, to match libcxx's
internal aligned `operator new`.
Differential Revision: https://reviews.llvm.org/D118190
These tests were formatted with older clang-format settings, this
updates them to the current settings.
In order to implement P2216 a lot of changes to these tests are
required. This makes it easier to review those patches.
https://cplusplus.github.io/LWG/issue3422
Also add a static_assert to check the "Mandates:" on the
iterator-pair constructor. Oddly, the `InputIterator` parameter
itself is merely preconditioned, not constrained, to satisfy the
input iterator requirements.
Also drive-by rename `init` to `__init`.
Differential Revision: https://reviews.llvm.org/D117962
* Default-initialized `basic_string` iterators are not portably in the domain of `==`.
* Avoid comparing iterators from non-equal string_views which MSVCSTL considers not to be in the domain of equality.
* Don't test invalid range `[in, out + N)`.
Also silence some truncation warnings by testing with a non-narrowing conversion.
Differential Revision: https://reviews.llvm.org/D118049
Since basic_string::reserve(n) is instantiated in the shared library but also
available to the compiler for inlining, its definition should not depend on
things like the Standard mode in use. Indeed, that flag may not match between
how the shared library is compiled and how users are compiling their own code,
resulting in ODR violations.
However, note that we retain the behavior of basic_string::reserve() to
shrink the string for backwards compatibility reasons. While it would
technically be conforming to not shrink, we believe user expectation is
for it to shrink, and so existing code might have been written based on
that assumption. We prefer to not break such code, even though that makes
basic_string::reserve() and basic_string::reserve(0) not equivalent anymore.
Fixes llvm-project#53170
Differential Revision: https://reviews.llvm.org/D117332
This implements the handler according to P0645. P2418 changes the wording
in the Standard. That isn't implemented and requires changes in more
places. LWG3631 applies modifications to P2418, but is currently
unresolved.
Implements parts of:
* P0645 Text Formatting
Depends on D115989
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D115991
[format.formatter.spec]/5 lists the requirements for the default
formatter. The original implementation didn't implement this. This
implements the default formatter according to the Standard.
This adds additional test to validate the default formatter is disabled
and the required standard formatters are enabled.
While adding the tests it seems the formatters needed a constraint for the
character types they were valid for.
Implements parts of:
- P0645 Text Formatting
Depends on D115988
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D115989
This implements the last required formatter specialization.
Completes:
- LWG 3251 Are std::format alignment specifiers applied to string arguments?
- LWG 3340 Formatting functions should throw on argument/format string mismatch in §[format.functions]
- LWG 3540 §[format.arg] There should be no const in basic_format_arg(const T* p)
Implements parts of:
- P0645 Text Formatting
Depends on D114001
Reviewed By: ldionne, vitaut, #libc
Differential Revision: https://reviews.llvm.org/D115988
This properly implements the formatter for floating-point types.
Completes:
- P1652R1 Printf corner cases in std::format
- LWG 3250 std::format: # (alternate form) for NaN and inf
- LWG 3243 std::format and negative zeroes
Implements parts of:
- P0645 Text Formatting
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D114001
Since their nested reference types are defined in terms of `iter_reference_t<T>`, which examines `decltype(*declval<T>())`.
Differential Revision: https://reviews.llvm.org/D117371
A number of the filesystem tests create a directory that contains a bad
symlink. On AIX recursively setting permissions on said directory will
return a non-zero value because of the bad symlink, however the
following rm -r still completes successfully. Avoid the assertion on
AIX, and rely on the return value of the remove command to detect
problems.
Differential Revision: https://reviews.llvm.org/D112086
Implement LWG3549 by making `view_interface` not inherit from `view_base`. Types
are still views if they have a public and unambiguous derivation from
`view_interface`, so adjust the `enable_view` machinery as such to account for
that.
Differential Revision: https://reviews.llvm.org/D117714
This will detect if someone writes `inline auto cpo =` instead of
`inline constexpr auto cpo =`. I don't know how that'd be possible,
but it's easy to test, so let's test it.
This addresses the usage of `operator&` in `<unordered_set>`.
(Note there are still more headers with the same issue.)
Reviewed By: #libc, philnik, Quuxplusone
Differential Revision: https://reviews.llvm.org/D117917
As discussed in https://reviews.llvm.org/D117714, there is missing test coverage
for the behavior of `enable_view` when given a const or reference qualified
type. Add such tests showing the current behavior.
Differential Revision: https://reviews.llvm.org/D117918
This addresses the usage of `operator&` in `<unordered_map>`.
(Note there are still more headers with the same issue.)
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D117393
This addresses the usage of `operator&` in `<unordered_map>`.
(Note there are still more headers with the same issue.)
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D117393
It was not in P0355R7, nor has it ever been so in a working draft.
Drive-by:
* tests should test something: fix loop bounds so initial value is not >= final value
* calender type streaming tests are useless - let's remove them
* don't declare printf, especially if you don't intend to use it
Differential Revision: https://reviews.llvm.org/D117638
As prefigured in the comments on D115315.
This gives us one unified style for all niebloids,
and also simplifies the modulemap.
Differential Revision: https://reviews.llvm.org/D116570
... rather than using `__has_builtin` directly. This both (1) allows a compiler that doesn't speak `__has_builtin` to workaround with preprocessor magic, and (2) avoids diagnostics about things that look like function like macros after `#if` but are not.
... it's easier to suppress warnings internally, where we can detect the compiler.
* Rename `TEST_COMPILER_C1XX` to `TEST_COMPILER_MSVC`
* Rename all `TEST_WORKAROUND_C1XX_<meow>` to `TEST_WORKAROUND_MSVC_<meow>`
Differential Revision: https://reviews.llvm.org/D117422
Currently it is not checked that operator in_in_result<II1, II2>() SFINAEs away properly
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D117517
The function `std::fill` requires a ForwardIterator, but `std::fill_n`
only requires an OutputIterator. Adds a test to validate `std::fill_n`
works with an OutputIterator.
Noticed this while working on LWG3539
format_to must not copy models of output_iterator<const charT&>
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D117395
Instead of storing the wrapped iterator inside the stride_counting_iterator,
store its base so we can have e.g. a stride_counting_iterator of an
input_iterator (which was previously impossible because input_iterators
are not copyable). Also a few other simplifications in stride_counting_iterator.
As a fly-by fix, remove the member base() functions, which are super
confusing.
Differential Revision: https://reviews.llvm.org/D116613
This change is the basis for a further refactoring where I'm going to
split up the various implementations we have in __threading_support to
make that code easier to understand.
Note that I had to make __convert_to_timespec a template to break
circular dependencies. Concretely, we never seem to use it with anything
other than ::timespec, but I am wary of hardcoding that assumption as
part of this change, since I suspect there's a reason for going through
these hoops in the first place.
Differential Revision: https://reviews.llvm.org/D116944
This essentially reverts e02ed1c255 and puts in a new fix, which makes `path::iterator`
a true C++20 `bidirectional_iterator`, but downgrades it to an `input_iterator` in C++17.
Fixes#37852.
Differential Revision: https://reviews.llvm.org/D116489
The code in libc++ already satisfy the requirements of LWG-3373. Since
the issue was written to specifically allow the types to be used in
structured bindings, tests have been added to validate the new
requirement.
Implements
LWG-3373 {to,from}_chars_result and format_to_n_result need the "we really mean what we say" wording
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D117337
I believe all four of these failures are directly due to the pattern where
allocations in the dylib are unobserved by the client program. If AIX32 and AIX64
don't support that, we should just disable the ASSERT_WITH_LIBRARY_INTERNAL_ALLOCATIONS
macro on AIX, and then we don't need to XFAIL these tests.
This also means I won't need to XFAIL a dozen other tests in D89057,
which rely heavily on ASSERT_WITH_LIBRARY_INTERNAL_ALLOCATIONS and
also currently fail on AIX.
See https://buildkite.com/llvm-project/libcxx-ci/builds/7669
Differential Revision: https://reviews.llvm.org/D116866
I didn't split the calendar bits more than this because there was little
benefit to doing it, and I know our calendar support is incomplete.
Whoever picks up the missing calendar bits can organize these headers
at their leisure.
Differential Revision: https://reviews.llvm.org/D116965
... from testing with MSVC's STL. Mostly truncation warnings and variables that are only used in `LIBCPP_ASSERT`.
Differential Revision: https://reviews.llvm.org/D116878
This makes all the tests consistent and improves code coverage. This also
uncovers a bug with negative indices in advance() (which also impacts
prev()) -- I'll fix that in a subsequent patch.
I chose to only count operations in the tests for ranges::advance because
doing so in prev() and next() too was reaching diminishing returns, and
didn't meaningfully improve our test coverage.
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
Arthur O'Dwyer