Note that this class was called just `split_view` in the original One
Ranges Proposal and was renamed to `lazy_split_view` by
[P2210](https://wg21.link/p2210).
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
Differential Revision: https://reviews.llvm.org/D107500
In the C++20 Standard time is no longer section under utilities, but
became its own chapter. This moves the time tests accordingly so their
location matches the current Standard.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122745
This supersedes and incoroporates content from both D108906 and D54966,
and also some original content.
Co-Authored-by: Marshall Clow <mclow.lists@gmail.com>
Co-Authored-by: Gonzalo Brito Gadeschi
Differential Revision: https://reviews.llvm.org/D118938
This change is done to see whether all platforms have a CI with the
Japanese locale installed.
This wires in the locale in the tests and uses it in one test. This is
a preparation for the tests of the chrono formatters.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122738
Before implementing P2216's format-string adjust the unit tests.
After P2216 the format* functions require a compile-time string literal.
This changes prepares the tests.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D122534
We are introducing branchless variants for sort3, sort4 and sort5.
These sorting functions have been generated using Reinforcement
Learning and aim to replace __sort3, __sort4 and __sort5 variants
for integral types.
The libc++ benchmarks were run on isolated machines for Skylake, ARM and
AMD architectures and achieve statistically significant improvement in
sorting random integers on test cases from sort1 to sort262144 for
uint32 and uint64.
A full performance overview for Intel Skylake, AMD and Arm can be
found here: https://bit.ly/3AtesYf
Reviewed By: ldionne, #libc, philnik
Spies: daniel.mankowitz, mgrang, Quuxplusone, andreamichi, philnik, libcxx-commits, nilayvaish, kristof.beyls
Differential Revision: https://reviews.llvm.org/D118029
This patch implements P0674R1, i.e. support for arrays in std::make_shared
and std::allocate_shared.
Co-authored-by: Zoe Carver <z.zoelec2@gmail.com>
Differential Revision: https://reviews.llvm.org/D62641
On Windows, like on macOS and FreeBSD, widening char(-5) in the
"C" locale succeeds and produces L'\u00fb'.
Switch widen_many to test \xfb instead of \x85; the mingw
version of btowc widens \x85 in the "C" locale into
\u2026 (which is the corresponding character according to the
Windows-1252 codepage), while Microsoft CRT's btowc widens it
into \u0085 (just like macOS and FreeBSD). Switch this to test \xfb
which is the character tested by the widen_1 test (as `char(-5)`),
which gets handled the same by all Windows implementations of btowc.
Differential Revision: https://reviews.llvm.org/D121003
[libc++] add global variable template std::views::empty
Note it is neither a range adaptor, nor a CPO. It is simplify a global variable template.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D122996
This iterator is used to test code that only needs to satisfy the
output_iterator concept. Follow-up changes will use this iterator in
older language Standards.
Reviewed By: ldionne, #libc, philnik, var-const
Differential Revision: https://reviews.llvm.org/D122072
Instead of using `.fail.cpp` tests, use `.verify.cpp` to check for the
exact reason of the failure. In the case of deduction guides, use SFINAE
based tests instead since that is our preferred way of testing those.
Finally, ensure that we actually run the test in `iter_alloc_deduction.pass.cpp`,
since we were not running anything before.
Differential Revision: https://reviews.llvm.org/D123055
The pointer.volatile.pass.cpp test was already marked as XFAIL for
mingw-dll (for reasons explained in the comment above it).
The same issue also appears in clang-cl-dll when built with newer
CMake versions. (It didn't appear with older versions of CMake, as
CMake built the library with the clang-cl flag `-std:c++latest` when
we've requested C++ 20 - which practically built it in c++2b mode with
current clang versions. With current versions of CMake, it passes
`-std:c++20` instead.)
As it succeeds/fails dependent on factors we don't
directly control, mark it as UNSUPPORTED instead of XFAIL.
Differential Revision: https://reviews.llvm.org/D122718
Instead of using a temporary `string` in `__vformat_to_wrapped` use a new
generic iterator. This aids to reduce the number of template instantions
and avoids using a `string` to buffer the entire formatted output.
This changes the type of `format_context` and `wformat_context`, this can
still be done since the code isn't ABI stable yet.
Several approaches have been evaluated:
- Using a __output_buffer base class with:
- a put function to store the buffer in its internal buffer
- a virtual flush function to copy the internal buffer to the output
- Using a `function` to forward the output operation to the output buffer,
much like the next method.
- Using a type erased function point to store the data in the buffer.
The last version resulted in the best performance. For some cases there's
still a loss of speed over the original method. This loss many becomes
apparent when large strings are copied to a pointer like iterator, before
the compiler optimized this using `memcpy`.
Reviewed By: ldionne, vitaut, #libc
Differential Revision: https://reviews.llvm.org/D110495
See https://reviews.llvm.org/D121626 for details -- this re-enables the
CTAD we removed, since it does break some stuff as well (even though it's
not nearly as bad as the removed constructors fixed by D121626).
Differential Revision: https://reviews.llvm.org/D122184
The test fails on AIX due to it expecting an error as on Linux. However, as on
other non-Linux systems symlinks permissions are supported so expect an empty
error code.
Reviewed By: daltenty, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D121140
These are the last™ changes to the tests for constexpr preparation.
Reviewed By: Quuxplusone, #libc, Mordante
Spies: Mordante, EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D120951
Before it only accepted one output iterator type. Now it accepts all
output iterator types as required by BasicFormatter.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D120916
Addresses LWG 3548 which mandates that when shared_ptr is being constructed from a unique_ptr, the unique_ptr's deleter should be moved and not copied.
Reviewed By: #libc, philnik, EricWF
Differential Revision: https://reviews.llvm.org/D119159
Changes in [P0896](https://wg21.link/p0896):
- add `disable_sized_sentinel_for`;
- add `iter_move` and `iter_swap`;
- add a `requires` clause to the `operator->`;
- add `iterator_concept`;
- check that the `Iterator` template parameter is a bidirectional
iterator;
- add constraints to all comparison operators;
- change the definitions of `iterator_category`, `value_type`,
`difference_type` and `reference` (changes to `iterator_category` were
already implemented).
Also add a few forgotten things to the `reverse_iterator` synopsis
(notably the spaceship operator).
Differential Revision: https://reviews.llvm.org/D120180
This should make CI consistent on all the compilers we support. Most of
this patch is working around various warnings emitted by GCC in our code
base, which are now being shown when we compile the tests.
After this patch, the whole test suite should be warning free on all
compilers we support and test, except for a few warnings on GCC that
we silence explicitly until we figure out the proper fix for them.
Differential Revision: https://reviews.llvm.org/D120684
All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly in
the tests, remove `// UNSUPPORTED: libcpp-no-concepts`.
Differential Revision: https://reviews.llvm.org/D121528
operator-> is not a requirement for most iterators, so remove it. To
account for this change, the `common_iterator.operator->` test needs to
be refactored quite a bit -- improve test coverage while we're at it.
Differential Revision: https://reviews.llvm.org/D118400
Now that we've branched for the LLVM 14 release, our support window
moves to clang-13 and clang-14. Similarly, AppleClang 13 has been
released for some time now, so that should be the oldest compiler
we support, per our policy.
A possible follow-up would be to remove _LIBCPP_HAS_NO_CONCEPTS, since
I don't think we support any compiler that doesn't support concepts
anymore.
Differential Revision: https://reviews.llvm.org/D118831
This reverts commit 276ca873. That commit has quite a history at this
point. It was first landed in dbc647643577, which broke std::shared_ptr<T const>
and was reverted in 9138666f5. It was then re-applied in 276ca873, with
the std::shared_ptr issue fixed, but it caused widespread breakage at
Google (which suggests it would cause similar breakage in the wild too),
so now I'm reverting again.
Instead, I will add a escape hatch that vendors can turn on to enable
the extension and perform a phased transition over one or two releases
like we sometimes do when things become non-trivial.
These tests don't seem specific to the debug mode, so it makes sense to
run them even when the debug mode is disabled. When we run with the debug
mode enabled, we'll get the out-of-bounds checking that this test seems
to be concerned with.
Differential Revision: https://reviews.llvm.org/D121241
Those older versions used a different monetary decimal separator.
To avoid unnecessary churn to support that, just XFAIL the test
on those older versions. (Up until
df1e43c496, the whole test was XFAILed
on all versions of glibc.)
Differential Revision: https://reviews.llvm.org/D120979
On Windows, constants like F::alpha and F::print are bitmasks
consisting of multiple bits (e.g. F::alpha consisting of both the
bits F::upper and F::lower). In such a case, we can't check that
all the bits from all the expected constants are set. Instead,
check that (p[i] & mask) != 0 returns the expected value.
Differential Revision: https://reviews.llvm.org/D120802
This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
implementations to reject std::allocator<cv T>, so allowing it is
really going against the current.
This was discovered in D120684: this extension required `const_cast`ing
in `__construct_range_forward`, a fishy bit of code that can be removed
if we don't support the extension anymore.
This is a re-application of dbc647643577, which was reverted in 9138666f5
because it broke std::shared_ptr<T const>. Tests have now been added and
we've made sure that std::shared_ptr<T const> wouldn't be broken in this
version.
Differential Revision: https://reviews.llvm.org/D120996
This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
implementations to reject std::allocator<cv T>, so allowing it is
really going against the current.
This was discovered in D120684: this extension required `const_cast`ing
in `__construct_range_forward`, a fishy bit of code that can be removed
if we don't support the extension anymore.
Differential Revision: https://reviews.llvm.org/D120996
AIX print -0.0 , inf, nan differently, which are causing the test
failures. We are OK for most other tests.
This patch remove the tests related these limitations conditionally on AIX,
so that we can enable the other tests to avoid losing test coverage.
The general direction is:
```
if strings don't differ between environments, keep the string literal "INF" and the padding, instead of folding them into variables.
```
Reviewed By: ldionne, #libc, Mordante
Differential Revision: https://reviews.llvm.org/D120448
Move `__quoted_output_proxy` into the one file that uses it.
A `const char*` has no associated traits class, so `std::quoted("literal")`
should be printable into any basic_ostream regardless of traits.
Use hidden-friend `operator<<` and `operator>>`, since we're permitted to.
(The exact signature is unspecified because the class itself is unspecified.)
We shouldn't support `std::quoted("literal")` in C++03 or C++11 mode.
(We do need `std::__quoted(s)` and `std::__quoted(cs)` in C++11 mode,
because they're used by `std::__fs::filesystem::path`.)
Differential Revision: https://reviews.llvm.org/D120135
Zero-sized types are a GCC extension, also supported by Clang.
In theory it's already invalid to `delete` a void pointer or a
pointer-to-incomplete, so we shouldn't need any special code
to catch those cases; but in practice Clang accepts both
constructs with just a warning, and GCC even accepts `sizeof(void)`
with just a warning! So we must keep the static_asserts.
The hard errors are tested in `unique_ptr_dltr_dflt/*.compile.fail.cpp`.
In ranges::begin/end, check `sizeof >= 0` instead of `sizeof != 0`,
so as to permit zero-sized types while still disallowing incomplete
types.
Fixes#54100.
Differential Revision: https://reviews.llvm.org/D120633
I believe the origin issue in PR31864 has been addressed by https://reviews.llvm.org/D59566.
As discussed in https://github.com/llvm/llvm-project/issues/53840, `ATOMIC_LLONG_LOCK_FREE == 2` sometimes is not consistent with `std::atomic<long long>::is_always_lock_free`, since the macro takes `long long`'s ABI alignment into account. https://reviews.llvm.org/D28213 proposed we should not rely on ABI alignment of types, thus we have consistent `ATOMIC_LLONG_LOCK_FREE` and `std::atomic<long long>::is_always_lock_free` on x86's old cpu. Currently, I plan to move on to remove the workaround which should have been addressed and don't want to break current tests.
Reviewed By: #libc, ldionne, Quuxplusone
Differential Revision: https://reviews.llvm.org/D119931
Previously, this test snippet would report incorrect information:
F::mask m;
std::wstring in(L"\u00DA"); // LATIN CAPITAL LETTER U WITH ACUTE
f.is(in.data(), in.data() + 1, &m);
// m & F::lower would be set
The single-character version of the `is` function wasn't
affected by this issue though.
Define `_LIBCPP_CTYPE_MASK_IS_COMPOSITE_ALPHA` for Windows,
as the `alpha` / `_ALPHA` constant is a mask consisting of
multiple bits set, which avoids setting `alpha` whenver any
of the bits is set, in the `do_is` implementation.
On Windows, with the "C" locale, wchars are classified according
to their Unicode interpretation, just as in the en_US.UTF-8 locale on
all platforms.
Due to the differing classification of some characters, the
`scan_is` and `scan_not` tests are quite annoying to fix, thus just
ifdef out some of the tests for the "C" locale there - the code gets
tested with the more standard en_US.UTF-8 locale anyway.
Differential Revision: https://reviews.llvm.org/D120796
Fixes LWG3656, "Inconsistent bit operations returning a count".
https://cplusplus.github.io/LWG/issue3656
The fix has been approved for C++23 and left to vendors' discretion
in C++20 (but it sounds like everyone's on the same page that
of course it should be DR'ed back to C++20 too).
Differential Revision: https://reviews.llvm.org/D120444
In the en_US locale on Windows, negative currency amounts is formatted
as "($0.01)" instead of "-$0.01".
Differential Revision: https://reviews.llvm.org/D120799
Change the tests to use the base friend function instead of members.
Also changed some types to have a base friends instead of members.
Reviewed By: #libc, ldionne, Quuxplusone
Differential Revision: https://reviews.llvm.org/D120742
`basic_ios` delays initialization of `__fill_` to `widen(' ')` until `fill()` is called. But, `fill(char_type)` is missing this logic, so the fill character does not get initialized to whitespace if `fill(char_type)` is called first. This patch adds this logic to `fill(char_type)`.
Reviewed By: #libc, ldionne, Quuxplusone
Differential Revision: https://reviews.llvm.org/D120751
Using -isystem marks the headers as system headers, which means that we
don't actually get all the warnings that we'd normally get if we included
the headers as user headers.
The goal of the test suite is normally to mirror as closely as possible
how users would use the library. Technically, this change goes against
that philosophy, since users should be using `-isystem` (if they ever
need to specify the libc++ path explicitly, which should be a rare
occurence). However, I believe fishing out additional warnings from
the headers provides more value, hence this change. Ideally, we'd be
able to still use `-isystem`, but instruct Clang to still emit warnings
from the libc++ headers (e.g. we could tell Clang to emit warnings in
any file inside `<...>/usr/include/c++/v1`).
Reviewed By: #libc, ldionne, #libc_abi
Spies: Mordante, EricWF, mstorsjo, mgorny, aheejin, arichardson, philnik, jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D118616
Note, reducing ios.width() in put_long_double instead of using variable
padding, when using a variable width symbol. Some of those tests didn't
actually trigger any padding in the existing form, with a longer
currency symbol; reduce the width so there's no actual padding with the
slightly shorter currency symbol either.
The tests for the international currency symbol use the same amount of
padding on all platforms, so they still exercise the padding properly.
Differential Revision: https://reviews.llvm.org/D120317
The old expected behaviour was specific to Apple platforms,
while Glibc, Windows and FreeBSD collate differently (ignoring
case). Make the old tested behaviour a special case for Apple
platforms, and make the default case the one used by the other
three.
In clang-cl/DLL configurations, the test is hit by
https://llvm.org/PR41018 (making the test fail to link).
Differential Revision: https://reviews.llvm.org/D120797
In the en_US locale on Windows, negative currency amounts is formatted
as "($0.01)" instead of "-$0.01".
Adjust the test references accordingly, making these tests pass.
Differential Revision: https://reviews.llvm.org/D120798
As part of https://reviews.llvm.org/D119036
(506cf6dc04), `-DNOMINMAX` was
dropped from the Windows CI configurations, replaced with a
block with `_LIBCPP_PUSH_MACROS`, `#include <__undef_macros>`
and `_LIBCPP_POP_MACROS` (and
`ADDITIONAL_COMPILE_FLAGS: -DNOMINMAX` left in two tests).
However, this workaround breaks the running the libc++ tests
against a different C++ standard library than libc++, as those
macros and that header are libc++ internals.
Therefore, reinstate `-DNOMINMAX` for clang-cl configurations
and remove the libc++ specific bits in filesystem_test_helper.h.
Differential Revision: https://reviews.llvm.org/D120478
AIX's system header provides these C++ overloads for compatibility with
older XL C++ implementations, but they can be disabled by defining
__LIBC_NO_CPP_MATH_OVERLOADS__ since AIX 7.2 TL 5 SP 3.
Since D109078 landed clang will define this macro when using libc++ on
AIX and we already run the lit tests with it too. This change will
enable the overloads in libc++'s math.h and we'll continue to require
the compiler to define the macro going forward.
Reviewed By: ldionne, jsji, EricWF
Differential Revision: https://reviews.llvm.org/D102172
co-authored-by: Jason Liu <jasonliu.development@gmail.com>
These printf()s fail to compile like so on hexagon:
.../tools/llvm-top/libcxx/test/std/utilities/charconv/charconv.msvc/test.cpp:94:23: error: format specifies type 'unsigned int' but the argument has type 'unsigned long' [-Werror,-Wformat]
printf("%u ", elem);
~~ ^~~~
%lu
.../tools/llvm-top/libcxx/test/std/utilities/charconv/charconv.msvc/test.cpp:569:56: error: format specifies type 'unsigned int' but the argument has type 'uint32_t' (aka 'unsigned long') [-Werror,-Wformat]
fprintf(stderr, "%s failed for 0x%08X\n", msg, bits);
~~~~ ^~~~
%08lX
.../tools/llvm-top/libcxx/test/std/utilities/charconv/charconv.msvc/test.cpp:1096:43: error: format specifies type 'unsigned int' but the argument has type 'unsigned long' [-Werror,-Wformat]
printf("Randomized test cases: %u\n", PrefixesToTest * Fractions);
~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
%lu
Differential Revision: https://reviews.llvm.org/D120532
These tests are hit hard by a bug that is fixed in a newer version
of UCRT. Add a test for the specific bug, and XFAIL the tests if
that bug is present (as it is in CI).
Split out hex formatting of floats to separate test files, that
are excluded with `XFAIL: msvc`. (Based on reading the C standard for
printf formatting, it seems like this isn't necessarily a proper bug
in printf, but just a case of differing optional behaviour.)
Differential Revision: https://reviews.llvm.org/D120022
All supported compilers have implemented this feature.
Therefore use the language version instead of the feature macro.
Reviewed By: #libc, philnik, ldionne, Quuxplusone
Differential Revision: https://reviews.llvm.org/D119865
International currency symbols (like USD, EUR) are returned with a
trailing space, like "USD ", on previously supported Unix platforms.
On Windows, the locales return them without a trailing space.
Also adjust the test for expecting a different unicode sequence for
the national currency symbol for ru_RU.UTF-8 and zh_CN.UTF-8.
Differential Revision: https://reviews.llvm.org/D120547
This follows the general direction of D118736 that
`_LIBCPP_HAS_NO_INCOMPLETE_RANGES` does *not* guard anything outside
of the `std::ranges::` namespace itself. This means we must permit
`ranges::less` etc. in no-ranges mode; that seems fine to me.
Differential Revision: https://reviews.llvm.org/D120139
The zh_CN.UTF-8 locale on Glibc has got `n_sign_posn == 4` (which means
having the negative sign just after the currency symbol), but has
`int_n_sign_posn == 1` (which means before the string).
On Windows, there's no separate `int_n_sign_posn` field, so the same
`n_sign_posn` (which is 4 there too) is used for international currency
formatting too. This makes the ordering for the international case on
Windows be the same as for the national one right above it.
On Apple platforms, the fr_FR.UTF-8 locale has got `n_sign_posn == 2`
but `p_sign_posn == 1`, giving a different order for the French locale
for the negative format.
On Apple platforms for the zh_CN.UTF-8 locale, both `n_sign_posn` and
`int_n_sign_posn` are 4, but `p_sign_posn` and `int_p_sign_posn` are 1.
Differential Revision: https://reviews.llvm.org/D120550
According to POSIX.1 (and Glibc docs, and Microsoft docs), the wctob
function returns EOF on error, not WEOF. (And wctob_l should consequently
do the same.)
The previous misconception about what this function returns on errors
seems to stem from incorrect documentation in macOS, stemming from BSD
docs with the same issue. The corresponding documentation bug in FreeBSD
was fixed in 2012 in
945aab9099,
but it hasn't been fixed for macOS yet.
The issue seems to only be a documentation issue; the implementation
on macOS actually does use EOF, not WEOF:
https://opensource.apple.com/source/Libc/Libc-1439.40.11/locale/FreeBSD/wctob.c.auto.html
On most Unices, EOF and WEOF are the same value, but on Windows,
EOF is -1, while WEOF is (unsigned short)0xFFFF. By fixing this,
two tests start passing on Windows.
Differential Revision: https://reviews.llvm.org/D120088
On Windows, the en_US.UTF-8 locale returns `n_sign_posn == 0`, which
means that the sign for a negative currency is parentheses around
the whole value, instead of a leading minus.
Differential Revision: https://reviews.llvm.org/D120549
This fixes issue #45084 (https://llvm.org/PR45739).
Remove unnecessary trailing spaces after the "RUB" international
currency symbol (and after the plain number in some parts of the
put_long_double test).
Both of these test files are
`XFAIL: netbsd || linux || LIBCXX-WINDOWS-FIXME`, and then have some of
their test cases commented out when `__APPLE__`. This patch comments-in
those test cases and adjusts them all to work on Apple, while leaving the
test `XFAIL`ed on NetBSD, Linux, and Windows.
Differential Revision: https://reviews.llvm.org/D120316
Set std::numeric_limits<>::tinyness_before to true for floating point types on ARM platforms.
Section E1.3.5 in the ARMv8 Architecture Reference Manual specifies:
Underflow. The bit is set to 1 if the absolute value of the result
of an operation, produced before rounding, is less than the minimum
positive normalized number for the destination precision, and the
rounded result is inexact.
Reviewed By: #libc, majnemer, EricWF
Differential Revision: https://reviews.llvm.org/D116338
AIX's libc generates "Error -1 occurred" instead of the "Unknown Error"
expected by these test cases. Add this as expected output for AIX only.
Reviewed By: daltenty, #powerpc, #libc, zibi, Quuxplusone
Differential Revision: https://reviews.llvm.org/D119982
Fixup tests that believe them to be so. Most notably including some heavy refactoring in `std/iterators/iterator.primitives/iterator.traits/cxx20_iterator_traits.compile.pass.cpp`, which now detects pointers and validates that `iterator_concept` is present only for pointers.
Differential Revision: https://reviews.llvm.org/D117368
Since Windows 10 version 1803 (10.0.17134.0) (or Windows Server 2019),
the Windows Universal C Runtime (UCRT) actually does support UTF-8
locales - they're available e.g. via the same names as commonly on Unices,
e.g. "en_US.UTF-8".
The UTF-8 locale support unfortunately has a bug which breaks a couple
tests that were passing previously. That bug is fixed in the very
latest version of the UCRT (in UCRT 10.0.20348.0, available in Windows
11 or Windows Server 2022), so it will get resolved at some point
eventually, provided that the CI environment does get upgraded to a
newer version of Windows Server.
While the net number of xfailed/passing tests in this patch is a loss,
this does allow fixing a lot more locale tests properly for Windows
in later patches.
Intentionally not touching the ISO-8859-1/2 locales used for testing;
they're not detected and tested/used right now, and fixing that up
is another project.
Differential Revision: https://reviews.llvm.org/D119930
Also apply the same fix on glibc. This takes the test one step closer
to passing on glibc, but it still fails on the zh_CN test (which
requires a more involved fix in libc++ itself).
Differential Revision: https://reviews.llvm.org/D119791
Expect the same NAN formatting on Windows as on Glibc. (Both MSVC and
MinGW produce the same formatting there.)
The hex float formatting tests pass on MinGW, so opt in to those tests.
Document exactly what issues are remaining in Clang-cl/MSVC
configurations. (It's easily possible to make the tests pass there too,
but it requires a whole lot of small-scope ifndefs in the test file;
around 60 ifdefs in total for those both test files. Those could
be avoided if the CI environment could run with a newer version
of UCRT, but that's nontrivial to fix right away.)
Differential Revision: https://reviews.llvm.org/D119766
It actually *is* important (for structured bindings) that `get(tuple)`
be ADL-able; but that's not the point of this test in particular.
Reviewed as part of D119860.
We shouldn't be calling `rethrow_exception` via ADL -- and neither should anybody
in the wild be calling it via ADL, so it's not like we need to test
this ADL ability of `rethrow_exception` in particular.
Reviewed as part of D119860.
We shouldn't be calling these functions via ADL -- and neither should anybody
in the wild be calling it via ADL, so it's not like we need to test
the ADL ability of these functions in particular.
Reviewed as part of D119860.
We shouldn't be calling `prev` via ADL -- and neither should anybody
in the wild be calling it via ADL, so it's not like we need to test
this ADL ability of `prev` in particular.
Reviewed as part of D119860.
We shouldn't be calling `next` via ADL -- and neither should anybody
in the wild be calling it via ADL, so it's not like we need to test
this ADL ability of `next` in particular.
Reviewed as part of D119860.
We shouldn't be calling `move` via ADL -- and neither should anybody
in the wild be calling it via ADL, so it's not like we need to test
this ADL ability of `move` in particular.
Reviewed as part of D119860.
The changes from the One Ranges Proposal amount to adding:
- a constructor that takes a `default_sentinel_t` and is equivalent to
the default constructor;
- an `operator==` that compares the iterator to `default_sentinel_t`.
The original proposal defined two overloads for `operator==` (different
argument order) as well as `operator!=`. This has been removed by
[P1614](https://wg21.link/p1614).
Differential Revision: https://reviews.llvm.org/D119620
We shouldn't be calling `distance` via ADL -- and neither should anybody
in the wild be calling it via ADL, so it's not like we need to test
this ADL ability of `distance` in particular.
Differential Revision: https://reviews.llvm.org/D119685
This should work now that we are using a matching libunwind.dylib when
we run the tests in back-deployment scenarios. The only restriction we
have now is to run on macOS x86_64, since that's what the old dylibs
were compiled for. This should allow us to move to newer AppleClangs
in the CI.
As a fly-by, fix missing availability annotations on optional's
monadic operations.
Differential Revision: https://reviews.llvm.org/D119840
As suggested in D117966.
These conditional noexcepts are *permitted* by the Standard (as long
as there were no mistakes in them, I guess); but not *mandated*.
The Standard doesn't put any noexcept-specifications on these member functions.
The same logic would apply to `transform_view::iterator::operator*`
and `transform_view::iterator::operator[]`, but the Standard mandates
conditional noexcept on `iter_move(transform_view::iterator)`, and
I think it doesn't make much sense to say "moving from this iterator
is conditionally noexcept but not-moving from it is noexcept(false),"
so I'm leaving transform_view alone for now.
Differential Revision: https://reviews.llvm.org/D119374
In src/, most files can use `constinit` directly because they're always
compiled with C++20. But some files, like "libcxxabi/src/fallback_malloc.cpp",
can't, because they're `#include`d directly from test cases in libcxxabi/test/
and therefore must (currently) compile as C++03. We might consider refactoring
those offending tests, or at least marking them `UNSUPPORTED: c++03`.
Differential Revision: https://reviews.llvm.org/D119264
The logic here is that we are disabling *only* things in `std::ranges::`.
Everything in `std::` is permitted, including `default_sentinel`, `contiguous_iterator`,
`common_iterator`, `projected`, `swappable`, and so on. Then, we include
anything from `std::ranges::` that is required in order to make those things
work: `ranges::swap`, `ranges::swap_ranges`, `input_range`, `ranges::begin`,
`ranges::iter_move`, and so on. But then that's all. Everything else (including
notably all of the "views" and the `std::views` namespace itself) is still
locked up behind `_LIBCPP_HAS_NO_INCOMPLETE_RANGES`.
Differential Revision: https://reviews.llvm.org/D118736
The test would trigger -Wtautological-compare. I think that the little
we gain from comparing addresses isn't worth the added complexity to
work around the warning.
This test feeds in the expected utf8 form of weekdays in various
languages, trying to match what libc++ has gathered internally
from `strftime()`. On glibc, the ru_RU.UTF-8 representation of the
tested weekday is spelled with upper case, while the existing
test reference is lower case.
Differential Revision: https://reviews.llvm.org/D118237
Also opt in to testing the hexadecimal float formatting for glibc; glibc
does matches the current test references there.
Differential Revision: https://reviews.llvm.org/D118238
`<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
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
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
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
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
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
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
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 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
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.
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
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 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
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
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
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
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.
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
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 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
Louis Dionne