Libc++ 21.0.0 (In-Progress) Release Notes¶

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.

Introduction ¶

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. All LLVM releases may be downloaded from the LLVM releases web site.

For more information about libc++, please see the Libc++ Web Site or the LLVM Web Site.

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.

What’s New in Libc++ 21.0.0?¶

Implemented Papers ¶

N4258: Cleaning-up noexcept in the Library (Github)
P0767R1: Deprecate POD (Github)
P1361R2: Integration of chrono with text formatting (Github)
P2255R2: A type trait to detect reference binding to temporary (implemented the type traits only) (Github)
P2372R3: Fixing locale handling in chrono formatters (Github)
P2562R1: constexpr Stable Sorting (Github)
P0472R3: Put std::monostate in <utility> (Github)
P1222R4: A Standard flat_set (Github)
P2897R7: aligned_accessor: An mdspan accessor expressing pointer over-alignment (Github)
P3247R2: Deprecate the notion of trivial types (Github)
P3372R3: constexpr containers and adaptors (Github) (forward_list, list, priority_queue, flat_map, and flat_set are implemented)
P2441R2: views::join_with (Github)
P2711R1: Making multi-param constructors of views explicit (Github)
P2770R0: Stashing stashing iterators for proper flattening (Github)
P2655R3: common_reference_t of reference_wrapper Should Be a Reference Type (Github)
P2944R3: Comparisons for reference_wrapper (Github)
P3379R0: Constrain std::expected equality operators (Github)

Improvements and New Features ¶

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 Hardening documentation for details.

Deprecations and Removals ¶

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.

Potentially breaking changes ¶

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.

Announcements About Future Releases ¶

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