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.
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 an intermediate and fairly mechanical step towards unifying the
benchmarks with the rest of the test suite. Moving this around requires
a few changes, notably making sure we don't throw a wrench into the
discovery process of the normal test suite. This won't be a problem
anymore once benchmarks are taken into account by the test setup out of
the box.
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
- LWG3147 Definitions of "likely" and "unlikely" are likely to cause
problems Adjusts the requirements on programs using the Standard
library.
- LWG3328 Clarify that std::string is not good for UTF-8 Adds a
non-normative note, aimed at users of the Standard library.
- LWG3784 std.compat should not provide ::byte and its friends was
implemented during modules.
- LWG3062 Unnecessary decay_t in is_execution_policy_v should be
remove_cvref_t Was implemented while implementing parallel algorithms.
- LWG3362 Strike stop_source's operator!= The removed operator was never
implemented.
- LWG3616 LWG 3498 seems to miss the non-member swap for basic_syncbuf
This was implemented correctly from the start.
- LWG3199 istream >> bitset<0> fails This was implemented in
fc4486c2472b84384d4a31d2436a91bdb9b29792, might be in LLVM-9
- LWG3828 Sync intmax_t and uintmax_t with C2x Standardardized existing
practice.
- LWG3713 Sorted with respect to comparator (only) Wording issue in the
Standard.
- LWG3823 Unnecessary precondition for is_aggregate Changes the
preconditions
- LWG3826 Redundant specification [for overload of yield_value] Changes
a remark to a note
- LWG3203 span element access invalidation Update wording relevant for
users of the Standard library.
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
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
~~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)
Implements parts of:
- P0355 Extending to chrono Calendars and Time Zones
- P1361 Integration of chrono with text formatting
- P2372 Fixing locale handling in chrono formatters
Implementing the Hermite polynomials which are part of C++17's
mathematical special functions. The goal is to get early feedback which
will make implementing the other functions easier. Integration of
functions in chunks (e.g. `std::hermite` at first, then `std::laguerre`,
etc.) might make sense as well (also see note on boost.math below).
I started out from this abandoned merge request:
https://reviews.llvm.org/D58876 .
The C++23 standard defines them in-terms of `/* floating-point type */`
arguments. I have not looked into that.
Note, there is still an ongoing discussion on discourse whether
importing boost.math is an option.
Implements [P1223R5][] completely.
Includes an implementation of `find_last`, `find_last_if`, and
`find_last_if_not`.
[P1223R5]: https://wg21.link/p1223r5
One-sided binary search, aka meta binary search, has been in the public
domain for decades, and has the general advantage of being constant time
in the best case, with the downside of executing at most 2*log(N)
comparisons vs classic binary search's exact log(N). There are two
scenarios in which it really shines: the first one is when operating
over non-random-access iterators, because the classic algorithm requires
knowing the container's size upfront, which adds N iterator increments
to the complexity. The second one is when traversing the container in
order, trying to fast-forward to the next value: in that case the
classic algorithm requires at least O(N*log(N)) comparisons and, for
non-random-access iterators, O(N^2) iterator increments, whereas the
one-sided version will yield O(N) operations on both counts, with a
best-case of O(log(N)) comparisons which is very common in practice.
These operators are absent in https://eel.is/c++draft/time.syn and a note in
https://eel.is/c++draft/time.cal.wd.overview#1 indicates that the absence is
intended.
This patch removes the undocumented extension, while providing a migration path
for vendors by providing the `_LIBCPP_ENABLE_REMOVED_WEEKDAY_RELATIONAL_OPERATORS`
macro. This macro will be honored for the LLVM 19 release and will be removed after
that, at which point allocator will be removed unconditionally.
There were some ad-hoc settings that allowed running the benchmarks
against the native C++ Standard Library. While this ability is very
useful, it was done before the test suite was quite independent of
libc++ itself. Instead, it is better to streamline running the
benchmarks on the native standard library by using a custom Lit
configuration like we do with the test suite.
A follow-up patch will rework the integration of benchmarks with the Lit
configuration used for the test suite so that we can reuse the same
mechanism for both, making it easy to benchmark the native standard
library.
It will also make benchmarks way more user-friendly to run since we will
be able to run them like we run individual tests, which is a pain point
right now.
These operators were deprecated in
P0768R1 Library Support for the Spaceship (Comparison) Operator
This was discovered while investigating the paper's implementation
status.
This patch implements P2389R2, which was adopted at the St. Louis meeting.
It builds upon previous enhancements from P2299R3, which introduced deduction
guides and the `dextents` alias template.
Previously, we would issue an #error when using a header that requires
threading support or localization support in a configuration where that
is disabled. This is unlike what we do for all the other carve outs like
no-filesystem, no-wide-characters or no-random-device. Instead of
issuing an #error, we normally just remove the problematic parts of the
header.
This patch makes the handling of no-localization and no-threads
consistent with the other carve-outs. I dislike the fact that users
won't get an explicit error message when trying to use e.g. ios in a
build that doesn't support localization, but I think it is better to
handle things consistently. Note that besides the consistency argument,
the #error approach doesn't really work anyways since it would break
down if we moved towards assuming the C locale only in the
no-localization mode.
This upcoming removal was recorded in the release notes for LLVM 19
as part of the deprecation of the C++20 synchronization library in
pre-C++20 modes, but wasn't included in "Upcoming Deprecations and Removals".
In order to define the format __cpp_lib_format to its initial value
(201907) these papers need to be completed:
- P0645R10 Text Formatting
- P1652R1 Printf corner cases in std::format
- 1361R2 Integration of chrono with text formatting The first two have
been implemented for a while the latter is almost done.
The next value (202106) requires:
- P2216R3 std::format improvements which has been implemented
The next value (202110) requires:
- P2418R2 Add support for std::generator-like types to std::format
- P2372R3 Fixing locale handling in chrono formatters The first one has
been implemented for a while the latter is almost done. The latter paper
is a DR against 1361R2 and both are implemented at the same time.
We've had user feedback that the missing of the __cpp_lib_format makes
their lives harder (https://github.com/llvm/llvm-project/issues/77773).
The missing papers 1361R2 and P2372R3 are very close to completion and
might completed before LLVM-19, but it will be a close call. This has
been discussed in the monthly libc++ meeting and we decided to set the
__cpp_lib_format so it will be set in LLVM-19.
Based on the discussion and the implementation status the
__cpp_lib_format is set to 202110.
Fixes#77773
Completes
- LWG3232 Inconsistency in zoned_time deduction guides
- LWG3294 zoned_time deduction guides misinterprets stringchar*
Implements parts of:
- P0355 Extending to chrono Calendars and Time Zones
Completes
- LWG3225 zoned_time converting constructor shall not be noexcept
- LWG3226 zoned_time constructor from string_view should accept
zoned_time<Duration2, TimeZonePtr2>
Implements parts of:
- P0355 Extending to chrono Calendars and Time Zones
This implements the class, its non-templated constructors and its
getters to verify the construction.
Completes
- LWG3224 zoned_time constructor from TimeZonePtr does not specify
initialization of tp_
Implements parts of:
- P0355 Extending chrono to Calendars and Time Zones
See [LWG4061](https://cplusplus.github.io/LWG/issue4061) and
[P3341R0](https://wg21.link/p3341r0). Effectively reverts commit
36ce0c3b1e581ca310ae7d0cbc6af002cc5d0251.
`libcxx/test/std/utilities/format/format.functions/bug_81590.compile.pass.cpp`
has a `format` function that unexpectedly takes the
`basic_format_context` by value, which is made ill-formed by LWG4061.
This PR changes the function to take the context by reference.
See [LWG4106](https://cplusplus.github.io/LWG/issue4106) and
[P3341R0](https://wg21.link/p3341r0).
The test coverage for the empty state of `basic_format_args` in
`get.pass.cpp` is to be completely removed, because the
non-default-constructibility is covered in `ctor.pass.cpp`.
