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
In LLVM 19 removed the extension with an opt-in macro. This finally
removes that option too and removes a few `const_cast`s where I know
that they exist only to support this extension.
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.
## 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)
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.
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
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
If the string is too long for a short string, we can simply check for
the long bit. If that's false we can do an early return. This improves
the code gen slightly.
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>
Instead of using **this in error messages for std::expected monadic
operations, use value(). As shown in LWG3969, **this can trigger
unintended ADL and while it's only an error message, we might as
well be ADL-correct there too.
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
We were not declaring `__uses_allocator_construction_args` helper
functions, leading to several valid uses failing to compile. This
patch solves the problem by moving these helper functions into a
struct, which also reduces the amount of redundant SFINAE we need
to perform since most overloads are checking for a cv-qualfied pair.
Fixes#66714
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
We originally put implementation-detail function objects into individual
namespaces for `std::ranges` without a good reason for doing so. This
practice was continued, presumably because there was prior art. Since
there's no reason to keep these namespaces, this commit removes them,
which will slightly impact binary size.
This commit does not apply to CPOs, some of which need additional work.
When we initially implemented the C++20 synchronization library, we
reluctantly accepted for the implementation to be backported to C++03
upon request from the person who provided the patch. This was when we
were only starting to have experience with the issues this can create,
so we flinched. Nowadays, we have a much stricter stance about not
backporting features to previous standards.
We have recently started fixing several bugs (and near bugs) in our
implementation of the synchronization library. A recurring theme during
these reviews has been how difficult to understand the current code is,
and upon inspection it becomes clear that being able to use a few recent
C++ features (in particular lambdas) would help a great deal. The code
would still be pretty intricate, but it would be a lot easier to reason
about the flow of callbacks through things like
__thread_poll_with_backoff.
As a result, this patch drops support for the synchronization library
before C++20. This makes us more strictly conforming and opens the door
to major simplifications, in particular around atomic_wait which was
supported all the way to C++03.
This change will probably have some impact on downstream users, however
since the C++20 synchronization library was added only in LLVM 10 (~3
years ago) and it's quite a niche feature, the set of people trying to
use this part of the library before C++20 should be reasonably small.
This is a follow up to https://github.com/llvm/llvm-project/pull/98717,
which made lock_guard available under _LIBCPP_HAS_NO_THREADS. We can
make unique_lock available under similar circumstances. This patch
follows the example in #98717, by:
- Removing the preprocessor guards for _LIBCPP_HAS_NO_THREADS in the
unique_lock header.
- providing a set of custom mutex implementations in a local header.
- using custom locks in tests that can be made to work under
`no-threads`.
Those two `__find_end` functions are no longer used after 101d1e9b3c86.
After that commit, `std::find_end` started dispatching to `__find_end_classic`,
and `ranges::find_end` to `__find_end_impl`, which means that the two `__find_end`
functions were no longer necessary.
Fixes#100569
`array<T, 0>::iterator` was always a pointer even when
`_LIBCXX_ABI_USE_WRAP_ITER_IN_STD_ARRAY` was defined. This patch fixes
that minor bug.
Discovered as part of [#100603][].
Drive-by: switch from `typedef` to `using` in `<array>`
[#100603]: https://github.com/llvm/llvm-project/pull/100603
This is a followup of https://github.com/llvm/llvm-project/pull/99343.
Since that patch was quite late in the LLVM-19 release cycle some of the
unneeded relational operator were not removed in C++20.
This removes them and gives the change a bit more "baking" time, just in
case there are issues with this change in user code. This change is
intended to be an NFC.
This adds the new std::enable_nonlocking_formatter_optimization trait in
<format>. This trait will be used in std::print to implement the
performance benefits.
Implements parts of
- P3107R5 - Permit an efficient implementation of ``std::print``
The polymorphic_allocator was added in C++17.
This issue was filed in 2022 so well after C++20. This issue adds an
operator==.
Starting with C++20 this adds a compiler generated operator!=. To have
the same behaviour in C++17 and C++20 (and later) a manual operator!= is
defined in C++17.
Implements
- LWG3683 operator== for polymorphic_allocator cannot deduce template
argument in common cases
The builtin __atomic_always_lock_free takes into account the type of the
pointer provided as the second argument. Because we were passing void*,
rather than T*, the calculation failed. This meant that
atomic_ref<T>::is_always_lock_free was only true for char & bool.
This bug exists elsewhere in the atomic library (when using GCC, we fail
to pass a pointer at all, and we fail to correctly align the atomic like
_Atomic would).
This change also attempts to start sorting out testing difficulties with
this function that caused the bug to exist by using the
__GCC_ATOMIC_(CHAR|SHORT|INT|LONG|LLONG|POINTER)_IS_LOCK_FREE predefined
macros to establish an expected value for `is_always_lock_free` and
`is_lock_free` for the respective types, as well as types with matching
sizes and compatible alignment values.
Using these compiler pre-defines we can actually validate that certain
types, like char and int, are actually always lock free like they are on
every platform in the wild.
Note that this patch was actually authored by Eric Fiselier but I picked
up the patch and GitHub won't let me set Eric as the primary author.
Co-authored-by: Eric Fiselier <eric@efcs.ca>
This speeds up the CI a bit (anecdotally ~10%) for those jobs, and it
also helps ensure that we are clean w.r.t. Clang modules when we disable
some of the carve-outs like no-localization or no-threads.
The `<locale>` header uses `strtoll_l` and friends which are defined in
`<xlocale.h>` on these platforms. While this works via transitive
includes when modules are disabled, this doesn't work anymore if the
platforms are modularized properly.
This implements the requirements for the container iterator requirements
for array, deque, vector, and `vector<bool>`.
Implements:
- LWG3352 strong_equality isn't a thing
Implements parts of:
- P1614R2 The Mothership has Landed
Fixes: https://github.com/llvm/llvm-project/issues/62486
This patch applies the comments provided on #84573. This is done as a
separate PR to avoid merge conflicts with downstreams that already had
ptrauth support.
The work was done in a8ae392718313e64e2d7bc092b00f51476c074b2 which
implements parts of
N4258: Cleaning-up noexcept in the Library
However that's paper Summary of Proposed Changes contains
No change in vector<bool>
This patch updates the status and as a few NFC cleanups. The fixed
version is based on the release page and might be off.
Updates
- LWG3778 vector<bool> missing exception specifications
The 3-dimentionsional `std::hypot(x,y,z)` was sub-optimally implemented.
This lead to possible over-/underflows in (intermediate) results which
can be circumvented by this proposed change.
The idea is to to scale the arguments (see linked issue for full
discussion).
Tests have been added for problematic over- and underflows.
Closes#92782
Pull request #96032 unconditionall adds the `cwchar` include in the
`format` umbrella header. However support for wchar_t can be disabled in
the build system (LIBCXX_ENABLE_WIDE_CHARACTERS).
This patch guards against inclusion of `cwchar` in `format` by checking
the `_LIBCPP_HAS_NO_WIDE_CHARACTERS` define.
For clarity I've also merged the include header section that `cwchar`
was in with the one above as they were both guarded by the same `#if`
logic.
~~NB: This PR depends on #78876. Ignore the first commit when reviewing,
and don't merge it until #78876 is resolved. When/if #78876 lands, I'll
clean this up.~~
This partially restores parity with the old, since removed debug build.
We now can re-enable a bunch of the disabled tests. Some things of note:
- `bounded_iter`'s converting constructor has never worked. It needs a
friend declaration to access the other `bound_iter` instantiation's
private fields.
- The old debug iterators also checked that callers did not try to
compare iterators from different objects. `bounded_iter` does not
currently do this, so I've left those disabled. However, I think we
probably should add those. See
https://github.com/llvm/llvm-project/issues/78771#issuecomment-1902999181
- The `std::vector` iterators are bounded up to capacity, not size. This
makes for a weaker safety check. This is because the STL promises not to
invalidate iterators when appending up to the capacity. Since we cannot
retroactively update all the iterators on `push_back()`, I've instead
sized it to the capacity. This is not as good, but at least will stop
the iterator from going off the end of the buffer.
There was also no test for this, so I've added one in the `std`
directory.
- `std::string` has two ambiguities to deal with. First, I opted not to
size it against the capacity. https://eel.is/c++draft/string.require#4
says iterators are invalidated on an non-const operation. Second,
whether the iterator can reach the NUL terminator. The previous debug
tests and the special-case in https://eel.is/c++draft/string.access#2
suggest no. If either of these causes widespread problems, I figure we
can revisit.
- `resize_and_overwrite.pass.cpp` assumed `std::string`'s iterator
supported `s.begin().base()`, but I see no promise of this in the
standard. GCC also doesn't support this. I fixed the test to use
`std::to_address`.
- `alignof.compile.pass.cpp`'s pointer isn't enough of a real pointer.
(It needs to satisfy `NullablePointer`, `LegacyRandomAccessIterator`,
and `LegacyContiguousIterator`.) `__bounded_iter` seems to instantiate
enough to notice. I've added a few more bits to satisfy it.
Fixes#78805
## Introduction
This patch implements LWG3618: Unnecessary `iter_move` for
`transform_view::iterator`.
`transform_view`'s iterator currently specifies a customization point
for `iter_move`. This customization point does the same thing that the
default implementation would do, but its sole purpose is to ensure the
appropriate conditional `noexcept` specification.
## Reference
-
[[range.transform.iterator]](https://eel.is/c++draft/range.transform.iterator)
- [LWG3618](https://cplusplus.github.io/LWG/issue3618)
