src/third_party/libc++/src/docs/ReleaseNotes/21.rst
.. contents:: :local: :depth: 2
Written by the Libc++ Team <https://libcxx.llvm.org>_
.. warning::
These are in-progress notes for the upcoming libc++ 21.0.0 release.
Release notes for previous releases can be found on
the Download Page <https://releases.llvm.org/download.html>_.
This document contains the release notes for the libc++ C++ Standard Library,
part of the LLVM Compiler Infrastructure, release 21.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/>_.
Github <https://github.com/llvm/llvm-project/issues/99937>__)Github <https://github.com/llvm/llvm-project/issues/104013>__)Github <https://github.com/llvm/llvm-project/issues/100014>__)Github <https://github.com/llvm/llvm-project/issues/105180>__)Github <https://github.com/llvm/llvm-project/issues/100043>__)constexpr Stable Sorting (Github <https://github.com/llvm/llvm-project/issues/105360>__)Github <https://github.com/llvm/llvm-project/issues/127874>__)flat_set (Github <https://github.com/llvm/llvm-project/issues/105193>__)aligned_accessor: An mdspan accessor expressing pointer over-alignment (Github <https://github.com/llvm/llvm-project/issues/118372>__)Github <https://github.com/llvm/llvm-project/issues/118387>__)constexpr containers and adaptors (Github <https://github.com/llvm/llvm-project/issues/127876>__) (forward_list, list, priority_queue, flat_map, and flat_set are implemented)views::join_with (Github <https://github.com/llvm/llvm-project/issues/105185>__)views explicit (Github <https://github.com/llvm/llvm-project/issues/105252>__)iterators for proper flattening (Github <https://github.com/llvm/llvm-project/issues/105250>__)common_reference_t of reference_wrapper Should Be a Reference Type (Github <https://github.com/llvm/llvm-project/issues/105260>__)std::expected equality operators (Github <https://github.com/llvm/llvm-project/issues/118135>__)The std::ranges::{copy, copy_n, copy_backward, move, move_backward, rotate} algorithms have been optimized for
std::vector<bool>::iterator, resulting in a performance improvement of up to 2000x.
The std::ranges::equal algorithm has been optimized for std::vector<bool>::iterator, resulting in a performance
improvement of up to 188x.
The std::ranges::swap_ranges algorithm has been optimized for std::vector<bool>::iterator, resulting in a
performance improvement of up to 611x.
Updated formatting library to Unicode 16.0.0.
The num_put::do_put integral overloads have been optimized, resulting in a performance improvement of up to 2.4x.
The std::stable_sort algorithm uses radix sort for floating-point types now, which can improve the performance
up to 10x, depending on type of sorted elements and the initial state of the sorted array.
The segmented iterator optimization for std::for_each has been backported to C++11. Previously it was only available
in C++23 and later.
The std::for_each_n, std::ranges::for_each and std::ranges::for_each_n algorithms have been optimized for
segmented iterators, resulting in a performance improvement of up to 17.7x for std::deque<short> iterators, and up
to 13.9x for std::join_view<vector<vector<short>>> iterators.
The bitset::to_string function has been optimized, resulting in a performance improvement of up to 8.3x for bitsets
with uniformly distributed zeros and ones, and up to 13.5x and 16.1x for sparse and dense bitsets, respectively.
The flat_map::insert and flat_set::insert_range have been optimized, resulting in a performance improvement of up
to 10x for inserting elements into a flat_map when the input range is a flat_map or a zip_view.
ctype::tolower and ctype::toupper have been optimized, resulting in a 2x performance improvement.
As an experimental feature, Hardening now supports assertion semantics that allow customizing how a hardening
assertion failure is handled. The four available semantics, modeled on C++26 Contracts, are ignore, observe,
quick-enforce and enforce. The observe semantic is intended to make it easier to adopt Hardening in
production but should not be used outside of this scenario. Please refer to the :ref:Hardening documentation <hardening> for details.
std::is_pod and std::is_pod_v are deprecated in C++20 and later.
std::is_trivial and std::is_trivial_v are deprecated in C++26 and later.
The _LIBCPP_VERBOSE_ABORT_NOT_NOEXCEPT has been removed, making std::__libcpp_verbose_abort
unconditionally noexcept.
libc++ no longer adds constexpr to std::hash<std::vector<bool, A>>::operator(), as the constexpr addition
since C++20 was an unintended extension.
The non-conforming extension packaged_task::result_type has been removed in LLVM 21.
The implementation of num_put::do_put has been replaced to improve the performance, which can lead to different
output when printing pointers.
User-defined specializations of std::common_reference are diagnosed now. To customize the common reference type, std::basic_common_reference should be specialized instead.
std::function used to have allocator support, which was removed from the Standard by http://wg21.link/p0302r1
due to issues with its design and inconsistent support from implementations. Previously, libc++ would provide
allocator-aware APIs in std::function in C++11 and C++14, but ignores the allocator argument in all places but
one. Starting in this release, the allocator argument is always ignored.
LLVM 22
- 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++.
ABI Affecting Changes
---------------------
- When using GCC, the ``std`` namespace is now annotated with ``[[gnu::visibility("default")]]``. This may cause more
symbols to be exported from shared libraries when building with ``-fvisibility=hidden``. This also fixes RTTI
comparison between shared libraries, since all RTTI has the correct visibility now. There is no behaviour change on
Clang.
- LLVM 20 contained an ABI break that can result in the size of ``std::unordered_{map,set,multimap,multiset}`` and ``std::deque`` changing when used with an allocator type that is empty and contains a base class that is the same across rebound allocator instantiations (e.g. ``Allocator<int>`` and ``Allocator<char>`` are both empty and contain the same base class).
In addition, the layout of a user-defined type that:
- contains one of the following containers: ``std::unordered_{map,set,multimap,multiset}``, ``std::deque``, ``std::map``, ``std::set``, ``std::multimap``, ``std::multiset``, ``std::list`` or ``std::vector``, and
- passes an empty allocator, comparator or hasher type to that container, and
- has a member of that same empty allocator, comparator or hasher type inside the enclosing struct, and
- that member is either marked with ``[[no_unique_address]]`` or optimized out via the EBO (empty base optimization) technique
saw its size increase from LLVM 19 to LLVM 20. This was caused by the usage of ``[[no_unique_address]]`` within some of libc++'s containers in a way that allowed subtle interactions with enclosing objects. This is fixed in LLVM 21 when using the Clang compiler (returning to the LLVM 19 ABI), however that implies an ABI break from LLVM 20 to LLVM 21.
Furthermore, fixing this causes a slight regression to constant evaluation support in ``std::unique_ptr``. Specifically, constant evaluation will now fail when the deleter relies on being value-initialized for constant-evaluation admissibility. If a default-initialized deleter can be used during constant evaluation, or if the default constructor is non-trivial, the ``unique_ptr`` is not affected by this regression. In particular, this regression does not impact any ``unique_ptr`` using the default deleter.
Note that there is currently no way to realistically fix this ABI break on GCC, therefore GCC will remain on the ABI introduced in LLVM 19. That also means that Clang and GCC will have a slightly different ABI for the small subset of types listed above until we are able to apply the same fix we did with Clang on GCC.
For more details see https://llvm.org/PR154146.
Build System Changes
--------------------
- TODO