This ABI break only affects fancy pointer which have a different value
representation when pointing to a base of T instead of T itself. This
seems like a rather small set of fancy pointers, which themselves
already represent a very small niche. This patch swaps a pointer to T
with a pointer to base of T in a few library-internal types.
Works towards P0619R4 / #99985.
The use of `std::get_temporary_buffer` and `std::return_temporary_buffer`
are replaced with `unique_ptr`-based RAII buffer holder.
Escape hatches:
- `_LIBCPP_ENABLE_CXX20_REMOVED_TEMPORARY_BUFFER` restores
`std::get_temporary_buffer` and `std::return_temporary_buffer`.
Drive-by changes:
- In `<syncstream>`, states that `get_temporary_buffer` is now removed,
because `<syncstream>` is added in C++20.
This significantly simplifies the code, improves compile times and
improves the object layout of types using `__compressed_pair` in the
unstable ABI. The only downside is that this is extremely ABI sensitive
and pedantically breaks the ABI for empty final types, since the address
of the subobject may change. The ABI of the whole object should not be
affected.
Fixes#91266Fixes#93069
There are a few lines in the release notes which are much wider than the
120 columns we usually use. This reflows the text to keep it below the
threshold.
We waited before supporting std::jthread fully because we wanted to
investigate other implementation strategies (in particular one involving
std::mutex). Since then, we did some benchmarking and decided that we
wouldn't be moving forward with std::mutex. Hence, there is no real
reason to punt on making std::jthread & friends non-experimental.
This patch implements https://wg21.link/P2747R2.
The library changes affect direct `operator new` and `operator new[]`
calls even when the core language changes are absent.
The changes are not available for MS ABI because the `operator new` and
`operator new[]` are from VCRuntime's `<vcruntime_new.h>`. A feature
request was submitted for that [1].
As a drive-by change, the patch reformatted the whole `new.pass.cpp` and
`new_array.pass.cpp` tests.
Closes#105427
[1]: https://developercommunity.visualstudio.com/t/constexpr-for-placement-operator-newope/10730304.
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>
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.
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
Instead of tracking those using our static CSV files, I created lists of
subtasks in their respective issues (#99939 and #105169) to track the
work that is still left.
This patch removes obsolete status pages for projects that were
completed: LLVM 18 release, C++20 Ranges and Spaceship support.
Co-authored-by: Hristo Hristov <zingam@outlook.com>
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.
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.
~~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
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".
This effort has quite a history:
- This was first attempted in 2022 via bed3240bf7d1, which broke
std::shared_ptr<T const> and caused the change to be reverted in
9138666f5464.
- We then re-attempted landing the change in 276ca87382b8 after fixing
std::shared_ptr, but reports were made that this broke code en masse
within Google. This led to the patch being reverted again in
a54d028895c9 with the goal to land this again with a migration path for
vendors.
This patch re-lands the removal while providing a migration path for
vendors by providing the `_LIBCPP_ENABLE_REMOVED_ALLOCATOR_CONST` macro.
This macro will be honored for the LLVM 19 release and will be removed
after that, at which point allocator<const T> will be removed
unconditionally.
Fixes#73665
This patch reverts 9b832b72 (#87111):
- [libc++] Deprecated `shared_ptr` Atomic Access APIs as per P0718R2
- [libc++] Implemented P2869R3: Remove Deprecated `shared_ptr` Atomic Access APIs from C++26
As explained in [1], the suggested replacement in P2869R3 is `__cpp_lib_atomic_shared_ptr`,
which libc++ does not yet implement. Let's not deprecate the old way of doing things before
the new way of doing things exists.
[1]: https://github.com/llvm/llvm-project/pull/87111#issuecomment-2112740039
I strongly suspect nobody ever used that macro since it wasn't very well
known. Furthermore, it only affects a handful of diagnostics and I think
it makes sense to either provide them unconditionally, or to not
provided them at all.
The change increments the size of the lookup table considerably. The
table has an "upper boundary" check. The removal of the code units with
the property Grapheme_Extend=Yes removes the range E0100..E01EF. This
breaks the trailing large continuous section in two parts. This will be
improved in a followup patch.
Implements:
- P2713R1 Escaping improvements in std::format
- LWG3965 Incorrect example in [format.string.escaped] p3 for formatting
of combining characters
```
---------------------------------------------------------
Benchmark Before After
---------------------------------------------------------
BM_ascii_escaped<char> 95696 ns 110704 ns
BM_unicode_escaped<char> 89311 ns 101371 ns
BM_cyrillic_escaped<char> 58633 ns 63329 ns
BM_japanese_escaped<char> 44500 ns 41223 ns
BM_emoji_escaped<char> 99156 ns 111022 ns
BM_ascii_escaped<wchar_t> 92245 ns 112441 ns
BM_unicode_escaped<wchar_t> 80970 ns 102776 ns
BM_cyrillic_escaped<wchar_t> 51253 ns 58977 ns
BM_japanese_escaped<wchar_t> 37252 ns 36885 ns
BM_emoji_escaped<wchar_t> 96226 ns 115885 ns
```
This patch finalizes the std::ranges::range_adaptor_closure
class template from https://wg21.link/P2387R3.
// [range.adaptor.object], range adaptor objects
template<class D>
requires is_class_v<D> && same_as<D, remove_cv_t<D>>
class range_adaptor_closure { };
The current implementation of __range_adaptor_closure was introduced
in ee44dd8062a26541808fc0d3fd5c6703e19f6016 and has served as the
foundation for the range adaptors in libc++ for a while. This patch
keeps its implementation, with the exception of the following changes:
- __range_adaptor_closure now includes the missing constraints
`is_class_v<D> && same_as<D, remove_cv_t<D>>` to restrict the
type of class that can inherit from it. (https://eel.is/c++draft/ranges.syn)
- The operator| of __range_adaptor_closure no longer requires its
first argument to model viewable_range. (https://eel.is/c++draft/range.adaptor.object#1)
- The _RangeAdaptorClosure concept is refined to exclude cases where
T models range or where T has base classes of type range_adaptor_closure<U>
for another type U. (https://eel.is/c++draft/range.adaptor.object#2)
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 deprecates support for the synchronization
library before C++20. In the next release, we can remove that support
entirely.
## Abstract
This pull request implements [P3029R1](https://wg21.link/P3029R1). The
paper discusses the current behavior of `mdspan`'s most common
pointer-indices CTAD, where the `Extents` template parameter is deduced
as `dextents` (dynamic extents), even when passing compile-time constant
values. The author believes this behavior is suboptimal, as it doesn't
take advantage of the compile-time information. The proposed change
suggests deducing static extents if `integral_constant`-like constants
are passed, resulting in more intuitive syntax and less error-prone
code.
## Reference
- [P3029R1](https://wg21.link/P3029R1)
- [Draft C++ Standard: [span.syn]](https://eel.is/c++draft/span.syn)
- [Draft C++ Standard: [mdspan.syn]](https://eel.is/c++draft/mdspan.syn)
