This patch implements https://wg21.link/p2609r3.
The test code was originally authored by JMazurkiewicz.
Notes:
- P2609R3 is not officially a Defect Report, but MSVC STL
implements it in C++20 mode.
Moreover, P2609R3 and P2997R1 touch exactly the same set of
concepts, and MSVC STL and libc++ have already treated P2997R1
as a DR.
- This patch also adjusted feature-test macros.
+ In C++20 mode, the value of __cpp_lib_ranges should be `202110L` because
- `202202L` covers `range_adaptor_closure` (P2387R3), and
- `202207L` covers move-only types in range adaptors (P2494R2).
And all of these changes are only available since C++23 mode.
+ In C++23 mode, the value should be `202406L` because
- `202211L` covers removing poison overloads (P2602R2),
- `202302L` covers relaxing projected value types (P2609R3), and
- `202406L` covers removing requirements on `iter_common_reference_t` (P2997R1).
And all of these changes are already or being implemented.
Fixes#105253.
Co-authored-by: Jakub Mazurkiewicz <mazkuba3@gmail.com>
## Why
Currently, the following does not work when compiled with clang:
```c++
#include <cmath>
struct ConvertibleToFloat {
operator float();
};
bool test(ConvertibleToFloat x) {
return std::isnormal(x);
}
```
See https://godbolt.org/z/5bos8v67T for differences with respect to
msvc, gcc or icx. It fails for `float`, `double` and `long double` (all
cv-unqualified floating-point types).
## What
Test and provide overloads as expected by the ISO C++ standard. The
classification/comparison function `isnormal` is defined since C++11
until C++23 as
```c++
bool isnormal( float num );
bool isnormal( double num );
bool isnormal( long double num );
```
and since C++23 as
```c++
constexpr bool isnormal( /* floating-point-type */ num );
```
for which "the library provides overloads for all cv-unqualified
floating-point types as the type of the parameter num". See §28.7.1/1 in
the [ISO C++
standard](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4950.pdf)
or check
[cppreference](https://en.cppreference.com/w/cpp/numeric/math/isnormal).
Works towards P0619R4/#99985.
- std::uncaught_exception was not previously deprecated. This patch
deprecates it since C++17 as per N4259. std::uncaught_exceptions is
used instead as libc++ unconditionally provides this function.
- _LIBCPP_ENABLE_CXX20_REMOVED_UNCAUGHT_EXCEPTION restores
std::uncaught_exception.
- As a drive-by, this patch updates the C++20 status page to
explain that D.11 is already done, since it was done in
578d09c1b195d859ca7e62840ff6bb83421a77b5.
#78086 provided the trait we want to use for this: `__libcpp_integer`.
In some `libcxx/containers/views/mdspan` tests, improper uses of `char`
are replaced with `signed char`.
Fixes#73715
A comment in `is_constructible.pass.cpp` suggests that Clang is
non-conforming in accepting construction of `const int&` from
`ExplicitTo<int&&>`.
This PR changes the test to expect the standard-conforming behavior,
which makes the test pass on MSVC.
This trait is implemented in C++26 conditionally on the compiler
supporting the __builtin_is_virtual_base_of intrinsic. I believe only
tip-of-trunk Clang currently implements that builtin.
Closes#105432
Followup to #99570.
* `TEST_COMPILER_MSVC` must be tested for `defined`ness, as it is
everywhere else.
+ Definition:
52a7116f5c/libcxx/test/support/test_macros.h (L71-L72)
+ Example usage:
52a7116f5c/libcxx/test/std/utilities/function.objects/func.not_fn/not_fn.pass.cpp (L248)
+ Fixes: `llvm-project\libcxx\test\support\atomic_helpers.h(33): fatal
error C1017: invalid integer constant expression`
* Fix bogus return type: `msvc_is_lock_free_macro_value()` returns `2`
or `0`, so it needs to return `int`.
+ Fixes: `llvm-project\libcxx\test\support\atomic_helpers.h(41): warning
C4305: 'return': truncation from 'int' to 'bool'`
* Clarity improvement: also add parens when mixing bitwise with
arithmetic operators.
PR #102851 marks reference types in union as error on msvc by changing
the clang, which makes 'transform_error.mandates.verify.cpp' no longer
failing on msvc from ToT. However, all libcxx buildbots do not build
clang from source, therefore, this test will still fail on these bots,
which is incorrect. This patch changed the expected error message of
this test so it can pass with both release branch clang and ToT clang.
Issue #43670 describes a situation where the following comparison will
issue a warning when -Wzero-as-null-pointer-constant is enabled:
#include <compare>
auto b = (1 <=> 2) < 0;
This code uses operator<(strong_ordering, Unspecified), which is
specified by the Standard to only work with a literal 0. In the library,
this is achieved by constructing Unspecified from a pointer, which works
but has the downside of triggering the warning.
This patch uses an alternative implementation where we require that the
operator is used exactly with an int of value 0 (known at compile-time),
however that value can technically be an expression like `1 - 1`, which
makes us a bit less strict than what's specified in the Standard.
Fixes#43670
This patch hardens the "test iterators" we use to test algorithms by
ensuring that they don't get double-moved. As a result of this
hardening, the tests started reporting multiple failures where we would
double-move iterators, which are being fixed in this patch.
In particular:
- Fixed a double-move in pstl.partition
- Add coverage for begin()/end() in subrange tests
- Fix tests for ranges::ends_with and ranges::contains, which were
incorrectly calling begin() twice on the same subrange containing
non-copyable input iterators.
Fixes#100709
Summary:
This used an old name I forgot to fix, linter didn't catch it because it
was behind `ifdef` and the branch which I tested it on I forgot to
update the one I landed.
Following up on https://github.com/llvm/llvm-project/pull/98841.
Changes:
- Properly test convertible types for `std::isnan()` and `std::inf()`
- Tighten conditional in `cmath.pass.cpp` (Find insights on `_LIBCPP_PREFERRED_OVERLOAD` below)
- Tighten preprocessor guard in `traits.h`
Insights into why `_LIBCPP_PREFERRED_OVERLOAD` is needed:
(i) When libc++ is layered on top of glibc on Linux, glibc's `math.h` is
included. When compiling with `-std=c++03`, this header brings the
function declaration of `isinf(double)` [1] and `isnan(double)` [2]
into scope. This differs from the C99 Standard as only the macros
`#define isnan(arg)` and `#define isinf(arg)` are expected.
Therefore, libc++ needs to respect the presense of the `double` overload
and cannot redefine it as it will conflict with the declaration already
in scope. For `-std=c++11` and beyond this issue is fixed, as glibc
guards both the `isinf` and `isnan` by preprocessor macros.
(ii) When libc++ is layered on top of Bionic's libc, `math.h` exposes a
function prototype for `isinf(double)` with return type `int`. This
function prototype in Bionic's libc is not guarded by any preprocessor
macros [3].
`_LIBCPP_PREFERRED_OVERLOAD` specifies that a given overload is a better match
than an otherwise equally good function declaration. This is implemented in
modern versions of Clang via `__attribute__((__enable_if__))`, and not elsewhere.
See [4] for details. We use `_LIBCPP_PREFERRED_OVERLOAD` to define overloads in
the global namespace that displace the overloads provided by the C
libraries mentioned above.
[1]: fe94080875/math/bits/mathcalls.h (L185-L194)
[2]: fe94080875/math/bits/mathcalls.h (L222-L231)
[3]: https://cs.android.com/android/platform/superproject/+/master:bionic/libc/include/math.h;l=322-323;drc=master?hl=fr-BE%22https:%2F%2Fsupport.google.com%2Fmerchants%2Fanswer%2F188494%5C%22%22https:%2F%2Fsupport.google.com%2Fmerchants%2Fanswer%2F188494%5C%22
[4]: 5fd17ab1b0
Trying to copy-construct a std::span from another std::span holding an
incomplete type would fail as we evaluate the SFINAE for the range-based
constructor. The problem was that we checked for __is_std_span after
checking for the range being a contiguous_range, which hard-errored
because of arithmetic on a pointer to incomplete type.
As a drive-by, refactor the whole test and format it.
Fixes#104496
Various functions like hash_value, lexically_proximate and lexically_relative
would incorrectly handle backslashes in the root directory on Windows, causing
behavior that is inconsistent with the equality comparison for a path.
Summary:
The `aligned_alloc` function is the C11 replacement for
`posix_memalign`. We should favor the C standard over the POSIX standard
so more C library implementations can run the tests.
Until https://github.com/llvm/llvm-project/pull/103056 lands
or another more appropriate check can be found.
This test fails on Ubuntu Focal where zdump is built with 32 bit time_t
but passes on Ubuntu Jammy where zdump is built with 64 bit time_t.
Marking it unsupported means Linaro can upgrade its bots to Ubuntu
Jammy without getting an unexpected pass.
Summary:
These assembly constraints are illegal / invalid on the AMDGPU target.
The `r` constraint is only valid on inputs and the `m` constraint isn't
accepted at all. The NVPTX target can handle them because it uses a more
permissive virtual machine (PTX is an IR). Simply add exceptions on the
target to make these work.
Summary:
This utility function gets a temp file to use for tests. It either uses
WIN32 or POSIX to create it. Some targets only follow the C standard,
and this test case will fail. This patch simply adds a fallback that
uses the `tmpnam` function from standard C. This function isn't ideal,
but it is good enough for our use-case.
---------
Co-authored-by: Mark de Wever <zar-rpg@xs4all.nl>
I had originally made some comments in https://reviews.llvm.org/D128214
that were followed when we implemented LWG2762. I don't understand why I
made these comments anymore, but either way it seems like I was wrong
since using `unique_ptr<void>::operator*` should be ill-formed. All
other implementations also make that ill-formed.
In practice, this test hasn't been run by any of the Windows
configurations so far, because it has been excluded by the "UNSUPPORTED:
clang-18, clang-19" line - but it does end up failing if running with
e.g. clang-20 on Windows.
As the test fails on more fundamental issues on Windows, mark it
outright unsupported on this platform; this fixes testing libcxx with a
recent nightly version of Clang from git main.
## Introduction
This patch implements LWG3564:
`transform_view::iterator<true>::value_type` and `iterator_category`
should use `const F&`.
`transform_view`'s iterator currently obtained from a `const
transform_view` invoke the transformation function as `const`, but the
`value_type` and `iterator_category` determination uses non-`const`
`F&`.
## Reference
-
[[range.transform.iterator]](https://eel.is/c++draft/range.transform.iterator)
- [LWG3564](https://cplusplus.github.io/LWG/issue3564)
The HEX float on z/OS does not have infinity nor NaN. In addition, the
limits are smaller before the overflow occurs in mathematical
calculations. This PR accounts for this.
FYI, this LIT test was recently added in PR
[89982](https://github.com/llvm/llvm-project/pull/89982)
This adds addressof at the required places in [input.output]. Some of
the new tests failed since string used operator& internally. These have
been fixed too.
Note the new fstream tests perform output to a basic_string instead of a
double. Using a double requires num_get specialization
num_get<CharT, istreambuf_iterator<CharT,
char_traits_operator_hijacker<CharT>>
This facet is not present in the locale database so the conversion would
fail due to a missing locale facet. Using basic_string avoids using the
locale.
As a drive-by fixes several bugs in the ofstream.cons tests. These
tested ifstream instead of ofstream with an open mode.
Implements:
- LWG3130 [input.output] needs many addressof
Closes#100246.
Changes the loop range to match similar tests and avoids zero
iterations. The original motivation to reduce the number of iterations
was to allow the test to be executed during constant evaluation.
Fixes: https://github.com/llvm/llvm-project/issues/100502
This is in relation to mr #93350. It was merged to main, but reverted
because of failing sanitizer builds on PowerPC.
The fix includes replacing the hard-coded threshold constants (e.g.
`__overflow_threshold`) for different floating-point sizes by a general
computation using `std::ldexp`. Thus, it should now work for all architectures.
This has the drawback of not being `constexpr` anymore as `std::ldexp`
is not implemented as `constexpr` (even though the standard mandates it
for C++23).
Closes#92782
We were only checking that the comparator was rvalue callable,
when in reality the algorithms always call comparators as lvalues.
This patch also refactors the tests for callable requirements and
expands it to a few missing algorithms.
This is take 2 of #73451, which was reverted because it broke some
CI bots. The issue was that we checked __is_callable with arguments
in the wrong order inside std::upper_bound. This has now been fixed
and a test was added.
Fixes#69554
The tests kept being based on std::string instead of std::string_view to
allow testing with older C++ dialects.
Adds tests for:
- LWG3112 system_error and filesystem_error constructors taking a string
may not be able to meet their postconditions
Investigating #96612 shows our implementation was different from the
Standard and could cause UB. Testing the codegen showed quite a bit of
assembly generated for these functions. The functions have been written
differently which allows Clang to optimize the code to use simple CPU
rotate instructions.
Fixes: https://github.com/llvm/llvm-project/issues/96612
The generator makes a few changes to the output
- removes the synopsis, it did not really show what was implemented
correctly.
- the output now is clang-format clean.
This code uses the new FTM data structure. Since the contents of this
structure are not up-to-date the code is only used in its tests.
This reverts commit 8d151f804ff43aaed1edf810bb2a07607b8bba14, which
broke some build bots. I think that is caused by an invalid argument
order when checking __is_comparable in upper_bound.
We were only checking that the comparator was rvalue callable,
when in reality the algorithms always call comparators as lvalues.
This patch also refactors the tests for callable requirements and
expands it to a few missing algorithms.
Fixes#69554
As mentioned in the LWG issue libc++ has already implemented the
optimization. This adds tests and documents the implementation defined
behaviour.
Drive-by fixes an initialization.
This patch increases the alignment requirement for std::atomic_ref
such that we can guarantee lockfree operations more often. Specifically,
we require types that are 1, 2, 4, 8, or 16 bytes in size to be aligned
to at least their size to be used with std::atomic_ref.
This is the case for most types, however a notable exception is
`long long` on x86, which is 8 bytes in length but has an alignment
of 4.
As a result of this patch, one has to be more careful about the
alignment of objects used with std::atomic_ref. Failure to provide
a properly-aligned object to std::atomic_ref is a precondition
violation and is technically UB. On the flipside, this allows us
to provide an atomic_ref that is actually lockfree more often,
which is an important QOI property.
More information in the discussion at https://github.com/llvm/llvm-project/pull/99570#issuecomment-2237668661.
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
