2024-01-25 13:36:50 -05:00
===========================================
Libc++ 19.0.0 (In-Progress) Release Notes
===========================================
.. contents ::
:local:
:depth: 2
Written by the `Libc++ Team <https://libcxx.llvm.org> `_
.. warning ::
These are in-progress notes for the upcoming libc++ 19.0.0 release.
Release notes for previous releases can be found on
`the Download Page <https://releases.llvm.org/download.html> `_ .
Introduction
============
This document contains the release notes for the libc++ C++ Standard Library,
part of the LLVM Compiler Infrastructure, release 19.0.0. Here we describe the
status of libc++ in some detail, including major improvements from the previous
release and new feature work. For the general LLVM release notes, see `the LLVM
documentation <https://llvm.org/docs/ReleaseNotes.html>`_. All LLVM releases may
be downloaded from the `LLVM releases web site <https://llvm.org/releases/> `_ .
For more information about libc++, please see the `Libc++ Web Site
<https://libcxx.llvm.org> `_ or the `LLVM Web Site <https://llvm.org> `_ .
Note that if you are reading this file from a Git checkout or the
main Libc++ web page, this document applies to the *next* release, not
the current one. To see the release notes for a specific release, please
see the `releases page <https://llvm.org/releases/> `_ .
What's New in Libc++ 19.0.0?
==============================
2024-07-23 18:59:23 +02:00
The main focus of the libc++ team has been to implement new C++20, C++23,
and C++26 features.
Experimental support for the time zone database has progressed.
2024-08-22 17:56:42 +03:00
Work on the ranges support has progressed.
2024-07-23 18:59:23 +02:00
Work on the experimental C++17 Parallel STL has progressed. See
:ref: `pstl-status` for the current status.
Work on the C++17 mathematical special functions has started. See
2024-08-23 11:44:45 -04:00
`this issue <https://github.com/llvm/llvm-project/issues/99939> `__
for the current status.
2024-07-23 18:59:23 +02:00
2024-01-25 13:36:50 -05:00
Implemented Papers
------------------
2024-02-01 13:31:25 +02:00
2024-07-19 06:38:02 +03:00
- P1132R8 - `` out_ptr `` - a scalable output pointer abstraction
2024-07-25 18:37:36 +02:00
- P1614R2 - The Mothership has Landed
2024-01-29 14:33:27 -05:00
- P2637R3 - Member `` visit ``
2024-02-01 13:31:25 +02:00
- P2652R2 - Disallow User Specialization of `` allocator_traits ``
2024-02-19 09:56:06 +02:00
- P2819R2 - Add `` tuple `` protocol to `` complex ``
2024-03-06 14:09:26 +02:00
- P2495R3 - Interfacing `` stringstream ` ` \s with ` ` string_view ``
2024-04-04 06:03:00 +03:00
- P2867R2 - Remove Deprecated `` strstream ` ` \s From C++26
2024-04-05 22:04:07 +03:00
- P2872R3 - Remove `` wstring_convert `` From C++26
2024-04-06 21:52:52 +03:00
- P3142R0 - Printing Blank Lines with `` println `` (as DR against C++23)
2024-05-09 12:48:37 +03:00
- P2944R3 - Comparisons for `` reference_wrapper `` (comparison operators for `` reference_wrapper `` only)
2024-07-18 13:26:37 +03:00
- P2591R5 - Concatenation of strings and string views
2024-07-11 00:05:23 +03:00
- P2968R2 - Make `` std::ignore `` a first-class object
2024-07-18 14:54:29 +03:00
- P2997R1 - Removing the common reference requirement from the indirectly invocable concepts (as DR against C++20)
2024-02-29 16:06:32 -08:00
- P2302R4 - `` std::ranges::contains ``
- P1659R3 - `` std::ranges::starts_with `` and `` std::ranges::ends_with ``
2024-04-12 13:25:22 -04:00
- P3029R1 - Better `` mdspan `` 's CTAD
2024-04-23 10:58:14 -04:00
- P2387R3 - Pipe support for user-defined range adaptors
2024-04-25 17:16:41 +02:00
- P2713R1 - Escaping improvements in `` std::format ``
2024-05-10 15:13:00 +01:00
- P2231R1 - Missing `` constexpr `` in `` std::optional `` and `` std::variant ``
2024-05-21 18:54:08 -04:00
- P0019R8 - `` std::atomic_ref ``
2024-07-15 23:23:34 +08:00
- P2389R2 - Alias template `` dims `` for the `` extents `` of `` mdspan ``
2024-07-19 09:42:16 -07:00
- P1223R5 - `` ranges::find_last() `` , `` ranges::find_last_if() `` , and `` ranges::find_last_if_not() ``
2024-07-23 18:59:23 +02:00
- P2602R2 - Poison Pills are Too Toxic
- P1981R0 - Rename `` leap `` to `` leap_second ``
- P1982R0 - Rename `` link `` to `` time_zone_link ``
2024-09-19 16:21:07 +02:00
- P2602R2 - Poison Pills are Too Toxic (as DR against C++20)
2024-07-23 18:59:23 +02:00
2024-01-25 13:36:50 -05:00
Improvements and New Features
-----------------------------
2024-02-04 00:28:29 +01:00
- The performance of growing `` std::vector `` has been improved for trivially relocatable types.
2024-07-23 18:59:23 +02:00
- A lot of types are considered trivially relocatable now, including `` std::vector `` and `` std::string `` .
- The performance of `` std::ranges::fill `` and `` std::ranges::fill_n `` has been improved for `` std::vector<bool>::iterator ` ` \s,
2024-03-17 20:00:54 +01:00
resulting in a performance increase of up to 1400x.
2024-07-23 18:59:23 +02:00
2024-03-23 15:28:22 +01:00
- The `` std::mismatch `` algorithm has been optimized for integral types, which can lead up to 40x performance
improvements.
2024-04-09 19:20:06 +02:00
2024-04-06 17:22:07 +02:00
- The `` std::ranges::minmax `` algorithm has been optimized for integral types, resulting in a performance increase of
up to 100x.
2024-01-25 13:36:50 -05:00
[libc++] Speed up set_intersection() by fast-forwarding over ranges of non-matching elements with one-sided binary search. (#75230)
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.
2024-07-18 21:11:24 +01:00
- The `` std::set_intersection `` and `` std::ranges::set_intersection `` algorithms have been optimized to fast-forward over
2024-07-23 18:59:23 +02:00
contiguous ranges of non-matching values, reducing the number of comparisons from linear to
[libc++] Speed up set_intersection() by fast-forwarding over ranges of non-matching elements with one-sided binary search. (#75230)
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.
2024-07-18 21:11:24 +01:00
logarithmic growth with the number of elements in best-case scenarios.
2024-04-04 06:03:00 +03:00
- The `` _LIBCPP_ENABLE_CXX26_REMOVED_STRSTREAM `` macro has been added to make the declarations in `` <strstream> `` available.
2024-04-05 22:04:07 +03:00
- The `` _LIBCPP_ENABLE_CXX26_REMOVED_WSTRING_CONVERT `` macro has been added to make the declarations in `` <locale> ``
available.
2024-04-09 19:20:06 +02:00
- The formatting library is updated to Unicode 15.1.0.
2024-07-11 00:05:23 +03:00
- `` std::ignore ` ` \s ` ` const __ignore_t& operator=(_Tp&&) const `` was changed to
`` const __ignore_type& operator=(const _Tp&) const noexcept `` for all language versions.
[libc++][hardening] Use bounded iterators in std::vector and std::string (#78929)
~~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
2024-07-22 22:44:25 -07:00
- Vendors can now configure the ABI so that `` string `` and `` vector `` will use bounded iterators when hardening is
enabled. Note that checks for iterator invalidation are currently not supported -- any accesses made through an
invalidated bounded iterator will still result in undefined behavior (bounded iterators follow the normal invalidation
rules of the associated container). `` string `` bounded iterators use the logical size of the container (`` index
< str.size()`` ) whereas ` ` vector `` bounded iterators use the "physical" size of the container (`` index
< vec.capacity()`` ) which is a less strict check; refer to the implementation for further details.
Bounded iterators can be enabled via the `` _LIBCPP_ABI_BOUNDED_ITERATORS_IN_STRING `` ABI macro for `` string `` and via
the `` _LIBCPP_ABI_BOUNDED_ITERATORS_IN_VECTOR `` ABI macro for `` vector `` ; note that checks will only be performed if
the hardening mode is set to `` fast `` or above (i.e., no checking is performed in the unchecked mode, even if bounded
iterators are enabled in the ABI configuration).
Note: bounded iterators currently are not supported for `` vector<bool> `` .
2024-07-23 18:59:23 +02:00
- In C++23 and C++26 the number of transitive includes in several headers has been reduced, improving the compilation speed.
2024-01-25 13:36:50 -05:00
Deprecations and Removals
-------------------------
2024-07-23 18:59:23 +02:00
- The C++20 synchronization library (`` <barrier> `` , `` <latch> `` , `` std::atomic::wait `` , etc.) has been deprecated
2024-04-16 10:57:48 -04:00
in language modes prior to C++20. If you are using these features prior to C++20, please update to `` -std=c++20 `` .
In LLVM 20, the C++20 synchronization library will be removed entirely in language modes prior to C++20.
2024-04-22 22:13:58 +02:00
- `` _LIBCPP_DISABLE_NODISCARD_EXT `` has been removed. `` [[nodiscard]] `` applications are now unconditional.
2024-07-23 18:59:23 +02:00
This decision is based on LEWGs discussion on `P3122 <https://wg21.link/P3122> `_ and `P3162 <https://wg21.link/P3162> `_
2024-04-22 22:13:58 +02:00
to not use `` [[nodiscard]] `` in the standard.
2024-07-12 15:07:12 -05:00
- The `` LIBCXX_ENABLE_ASSERTIONS `` CMake variable that was used to enable the safe mode has been deprecated and setting
2024-01-25 13:36:50 -05:00
it triggers an error; use the `` LIBCXX_HARDENING_MODE `` CMake variable with the value `` extensive `` instead. Similarly,
the `` _LIBCPP_ENABLE_ASSERTIONS `` macro has been deprecated (setting it to `` 1 `` still enables the extensive mode in
the LLVM 19 release while also issuing a deprecation warning). See :ref:`the hardening documentation
<using-hardening-modes>` for more details.
[libc++] Remove deprecated char_traits base template (#72694)
This patch has quite a bit of history. First, it must be noted that the
Standard only specifies specializations of char_traits for char,
char8_t, char16_t, char32_t and wchar_t. However, before this patch, we
would provide a base template that accepted anything, and as a result
code like `std::basic_string<long long>` would compile but nobody knows
what it really does. It basically compiles by accident.
We marked the base template as deprecated in LLVM 15 or 16 and were
planning on removing it in LLVM 17, which we did in e30a148b098d.
However, it turned out that the deprecation warning had never been
visible in user code since Clang did not surface that warning from
system headers. As a result, this caught people by surprise and we
decided to reintroduce the base template in LLVM 17 in cce062d226ba.
Since then, #70353 changed Clang so that such deprecation warnings would
be visible from user code. Hence, this patch closes the loop and removes
the deprecated specializations.
2024-01-30 08:45:28 -05:00
- The base template for `` std::char_traits `` has been removed in LLVM 19. If you are using `` std::char_traits `` with
2024-01-25 13:36:50 -05:00
types other than `` char `` , `` wchar_t `` , `` char8_t `` , `` char16_t `` , `` char32_t `` or a custom character type for which you
specialized `` std::char_traits `` , your code will stop working. The Standard does not mandate that a base template is
provided, and such a base template is bound to be incorrect for some types, which could currently cause unexpected behavior
while going undetected.
2024-03-13 09:00:53 -04:00
- The `` _LIBCPP_ENABLE_NARROWING_CONVERSIONS_IN_VARIANT `` macro that changed the behavior for narrowing conversions
2024-01-25 13:36:50 -05:00
in `` std::variant `` has been removed in LLVM 19.
2024-03-21 17:48:13 +01:00
- The `` _LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS `` and `` _LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION ``
macros have been removed in LLVM 19.
2024-01-25 13:36:50 -05:00
2024-04-16 20:20:37 +02:00
- The `` _LIBCPP_ENABLE_CXX17_REMOVED_FEATURES `` and `` _LIBCPP_ENABLE_CXX20_REMOVED_FEATURES `` macros have
2024-01-25 13:36:50 -05:00
been removed in LLVM 19. C++17 and C++20 removed features can still be re-enabled individually.
2024-01-30 07:51:20 -05:00
- The `` _LIBCPP_INLINE_VISIBILITY `` and `` _VSTD `` macros have been removed in LLVM 19.
2024-01-25 13:36:50 -05:00
2024-02-27 17:31:02 -05:00
- The `` _LIBCPP_ATOMIC_ONLY_USE_BUILTINS `` configuration option has been removed in LLVM 19. This should not affect
many users, except perhaps users using the library with `` -ffreestanding `` with a toolchain where compiler-rt or
libatomic is not available. If you are one such user, please reach out to the libc++ developers so we can collaborate
on a path for supporting atomics properly on freestanding platforms.
2024-04-06 20:33:41 +08:00
- LWG3430 disallow implicit conversion of the source arguments to `` std::filesystem::path `` when
constructing `` std::basic_*fstream `` . This effectively removes the possibility to directly construct
a `` std::basic_*fstream `` from a `` std::basic_string_view `` , a input-iterator or a C-string, instead
you can construct a temporary `` std::basic_string `` . This change has been applied to C++17 and later.
2024-05-01 10:26:38 -06:00
- The `` _LIBCPP_DISABLE_ADDITIONAL_DIAGNOSTICS `` macro has been removed and is not honored anymore. Additional
warnings provided by libc++ as a matter of QoI will now be provided unconditionally.
2024-06-25 09:19:55 -05:00
- libc++ no longer supports `` std::allocator<const T> `` and containers of `` const `` -qualified element type, such
as `` std::vector<const T> `` and `` std::list<const T> `` . This used to be supported as an undocumented extension.
If you were using `` std::vector<const T> `` , replace it with `` std::vector<T> `` instead. The
2024-07-23 18:59:23 +02:00
`` _LIBCPP_ENABLE_REMOVED_ALLOCATOR_CONST `` macro can be defined to temporarily re-enable this extension.
to temporarily re-enable this extension to make it easier to update user code
This macro will be honored for one released and ignored starting in LLVM 20.
2024-06-25 09:19:55 -05:00
To assist with the clean-up process, consider running your code through Clang Tidy, with
2024-07-23 18:59:23 +02:00
`std-allocator-const <https://clang.llvm.org/extra/clang-tidy/checks/portability/std-allocator-const.html> `_
2024-06-25 09:19:55 -05:00
enabled.
2024-07-15 09:11:23 -05:00
- When configuring libc++ with localization or threads disabled, the library no longer emits an error when
trying to `` #include <locale> `` and other such headers. Instead, those headers have no content. This is
consistent with the behavior for all other libc++ carve-outs like filesystem, wide characters, a source
of randomness, and others. Users that were checking whether including a header would fail (e.g. via a script
or CMake's `` try_compile `` will experience a change in behavior).
2024-07-18 21:58:35 +08:00
- libc++ no longer supports relational comparison for `` std::chrono::weekday `` . The relational comparison operators were
provided as an undocumented extension. If you were using relational comparison on `` std::chrono::weekday `` , compare
the results of `` c_encoding() `` or `` iso_encoding() `` instead. The
`` _LIBCPP_ENABLE_REMOVED_WEEKDAY_RELATIONAL_OPERATORS `` macro can be defined to temporarily re-enable this extension.
This macro will be honored for one release and ignored starting in LLVM 20.
2024-07-17 18:21:36 +02:00
- The operators in the `` rel_ops `` namespace have been deprecated. The deprecation is part of the paper
P0768R1 "Library Support for the Spaceship (Comparison) Operator".
2024-03-18 16:53:37 +01:00
2024-01-25 13:36:50 -05:00
Upcoming Deprecations and Removals
----------------------------------
LLVM 20
~~~~~~~
- The `` LIBCXX_ENABLE_ASSERTIONS `` CMake variable and the `` _LIBCPP_ENABLE_ASSERTIONS `` macro that were used to enable
the safe mode will be removed in LLVM 20.
2024-07-10 14:10:30 -04:00
- The C++20 synchronization library will be removed entirely in language modes prior to C++20 in LLVM 20.
2024-07-18 21:58:35 +08:00
- The relational operators for `` std::chrono::weekday `` will be removed entirely, and the
`` _LIBCPP_ENABLE_REMOVED_WEEKDAY_RELATIONAL_OPERATORS `` macro that was used to re-enable this extension will be
ignored in LLVM 20.
2024-07-23 18:59:23 +02:00
- The `` _LIBCPP_ENABLE_REMOVED_ALLOCATOR_CONST `` macro will no longer have an effect.
2024-01-25 13:36:50 -05:00
LLVM 21
~~~~~~~
2024-07-18 18:04:19 +02:00
- The status of the C++03 implementation will be frozen after the LLVM 21 release. This means that starting in LLVM 22, non-critical bug fixes may not be back-ported
to C++03, including LWG issues. C++03 is a legacy platform, where most projects are no longer actively maintained. To
reduce the amount of fixes required to keep such legacy projects compiling with up-to-date toolchains, libc++ will aim to freeze the status of the headers in C++03 mode to avoid unintended breaking changes.
See https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc for more details.
If you are using C++03 in your project, you should consider moving to a newer version of the Standard to get the most out of libc++.
2024-01-25 13:36:50 -05:00
2024-07-23 18:59:23 +02:00
2024-01-25 13:36:50 -05:00
ABI Affecting Changes
---------------------
2024-04-09 19:13:02 +02:00
- The optional POSIX macro `` ENODATA `` has been deprecated in C++ and POSIX 2017. The
`` random_device `` could throw a `` system_error `` with this value. It now
throws `` ENOMSG `` .
2024-01-25 13:36:50 -05:00
Build System Changes
--------------------
2024-02-26 14:46:15 -05:00
- The `` LIBCXX_EXECUTOR `` and `` LIBCXXABI_EXECUTOR `` CMake variables have been removed. Please
set `` LIBCXX_TEST_PARAMS `` to `` executor=<...> `` instead.
2024-04-13 12:32:46 +02:00
2024-07-23 18:59:23 +02:00
- The CMake variable `` LIBCXX_ENABLE_CLANG_TIDY `` has been removed. The build system has been changed
2024-04-13 12:32:46 +02:00
to automatically detect the presence of `` clang-tidy `` and the required `` Clang `` libraries.
2024-04-28 14:12:27 +02:00
- The CMake options `` LIBCXX_INSTALL_MODULES `` now defaults to `` ON `` .
2024-07-17 12:20:48 -05:00
- The CMake options `` LIBCXX_BENCHMARK_NATIVE_STDLIB `` and `` LIBCXX_BENCHMARK_NATIVE_GCC_TOOLCHAIN `` have
been removed. To benchmark the native standard library, configure the test suite against the native
standard library directly instead.