170 lines · plain
1===========================================2Libc++ 21.0.0 (In-Progress) Release Notes3===========================================4 5.. contents::6 :local:7 :depth: 28 9Written by the `Libc++ Team <https://libcxx.llvm.org>`_10 11.. warning::12 13 These are in-progress notes for the upcoming libc++ 21.0.0 release.14 Release notes for previous releases can be found on15 `the Download Page <https://releases.llvm.org/download.html>`_.16 17Introduction18============19 20This document contains the release notes for the libc++ C++ Standard Library,21part of the LLVM Compiler Infrastructure, release 21.0.0. Here we describe the22status of libc++ in some detail, including major improvements from the previous23release and new feature work. For the general LLVM release notes, see `the LLVM24documentation <https://llvm.org/docs/ReleaseNotes.html>`_. All LLVM releases may25be downloaded from the `LLVM releases web site <https://llvm.org/releases/>`_.26 27For more information about libc++, please see the `Libc++ Web Site28<https://libcxx.llvm.org>`_ or the `LLVM Web Site <https://llvm.org>`_.29 30Note that if you are reading this file from a Git checkout or the31main Libc++ web page, this document applies to the *next* release, not32the current one. To see the release notes for a specific release, please33see the `releases page <https://llvm.org/releases/>`_.34 35What's New in Libc++ 21.0.0?36==============================37 38Implemented Papers39------------------40 41- N4258: Cleaning-up noexcept in the Library (`Github <https://github.com/llvm/llvm-project/issues/99937>`__)42- P0767R1: Deprecate POD (`Github <https://github.com/llvm/llvm-project/issues/104013>`__)43- P1361R2: Integration of chrono with text formatting (`Github <https://github.com/llvm/llvm-project/issues/100014>`__)44- P2255R2: A type trait to detect reference binding to temporary (implemented the type traits only) (`Github <https://github.com/llvm/llvm-project/issues/105180>`__)45- P2372R3: Fixing locale handling in chrono formatters (`Github <https://github.com/llvm/llvm-project/issues/100043>`__)46- P2562R1: ``constexpr`` Stable Sorting (`Github <https://github.com/llvm/llvm-project/issues/105360>`__)47- P0472R3: Put std::monostate in <utility> (`Github <https://github.com/llvm/llvm-project/issues/127874>`__)48- P1222R4: A Standard ``flat_set`` (`Github <https://github.com/llvm/llvm-project/issues/105193>`__)49- P2897R7: ``aligned_accessor``: An mdspan accessor expressing pointer over-alignment (`Github <https://github.com/llvm/llvm-project/issues/118372>`__)50- P3247R2: Deprecate the notion of trivial types (`Github <https://github.com/llvm/llvm-project/issues/118387>`__)51- P3372R3: ``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)52- P2441R2: ``views::join_with`` (`Github <https://github.com/llvm/llvm-project/issues/105185>`__)53- P2711R1: Making multi-param constructors of ``views`` ``explicit`` (`Github <https://github.com/llvm/llvm-project/issues/105252>`__)54- P2770R0: Stashing stashing ``iterators`` for proper flattening (`Github <https://github.com/llvm/llvm-project/issues/105250>`__)55- P2655R3: ``common_reference_t`` of ``reference_wrapper`` Should Be a Reference Type (`Github <https://github.com/llvm/llvm-project/issues/105260>`__)56- P3379R0: Constrain ``std::expected`` equality operators (`Github <https://github.com/llvm/llvm-project/issues/118135>`__)57 58Improvements and New Features59-----------------------------60 61- The ``std::ranges::{copy, copy_n, copy_backward, move, move_backward, rotate}`` algorithms have been optimized for62 ``std::vector<bool>::iterator``, resulting in a performance improvement of up to 2000x.63 64- The ``std::ranges::equal`` algorithm has been optimized for ``std::vector<bool>::iterator``, resulting in a performance65 improvement of up to 188x.66 67- The ``std::ranges::swap_ranges`` algorithm has been optimized for ``std::vector<bool>::iterator``, resulting in a68 performance improvement of up to 611x.69 70- Updated formatting library to Unicode 16.0.0.71 72- The ``num_put::do_put`` integral overloads have been optimized, resulting in a performance improvement of up to 2.4x.73 74- The ``std::stable_sort`` algorithm uses radix sort for floating-point types now, which can improve the performance75 up to 10x, depending on type of sorted elements and the initial state of the sorted array.76 77- The segmented iterator optimization for ``std::for_each`` has been backported to C++11. Previously it was only available78 in C++23 and later.79 80- The ``std::for_each_n``, ``std::ranges::for_each`` and ``std::ranges::for_each_n`` algorithms have been optimized for81 segmented iterators, resulting in a performance improvement of up to 17.7x for ``std::deque<short>`` iterators, and up82 to 13.9x for ``std::join_view<vector<vector<short>>>`` iterators.83 84- The ``bitset::to_string`` function has been optimized, resulting in a performance improvement of up to 8.3x for bitsets85 with uniformly distributed zeros and ones, and up to 13.5x and 16.1x for sparse and dense bitsets, respectively.86 87- The ``flat_map::insert`` and ``flat_set::insert_range`` have been optimized, resulting in a performance improvement of up88 to 10x for inserting elements into a ``flat_map`` when the input range is a ``flat_map`` or a ``zip_view``.89 90- ``ctype::tolower`` and ``ctype::toupper`` have been optimized, resulting in a 2x performance improvement.91 92- As an experimental feature, Hardening now supports assertion semantics that allow customizing how a hardening93 assertion failure is handled. The four available semantics, modeled on C++26 Contracts, are ``ignore``, ``observe``,94 ``quick-enforce`` and ``enforce``. The ``observe`` semantic is intended to make it easier to adopt Hardening in95 production but should not be used outside of this scenario. Please refer to the :ref:`Hardening documentation96 <hardening>` for details.97 98Deprecations and Removals99-------------------------100 101- ``std::is_pod`` and ``std::is_pod_v`` are deprecated in C++20 and later.102 103- ``std::is_trivial`` and ``std::is_trivial_v`` are deprecated in C++26 and later.104 105- The ``_LIBCPP_VERBOSE_ABORT_NOT_NOEXCEPT`` has been removed, making ``std::__libcpp_verbose_abort``106 unconditionally ``noexcept``.107 108- libc++ no longer adds ``constexpr`` to ``std::hash<std::vector<bool, A>>::operator()``, as the ``constexpr`` addition109 since C++20 was an unintended extension.110 111- The non-conforming extension ``packaged_task::result_type`` has been removed in LLVM 21.112 113Potentially breaking changes114----------------------------115 116- The implementation of ``num_put::do_put`` has been replaced to improve the performance, which can lead to different117 output when printing pointers.118 119- User-defined specializations of ``std::common_reference`` are diagnosed now. To customize the common reference type, ``std::basic_common_reference`` should be specialized instead.120 121- ``std::function`` used to have allocator support, which was removed from the Standard by `http://wg21.link/p0302r1`122 due to issues with its design and inconsistent support from implementations. Previously, libc++ would provide123 allocator-aware APIs in ``std::function`` in C++11 and C++14, but ignores the allocator argument in all places but124 one. Starting in this release, the allocator argument is always ignored.125 126Announcements About Future Releases127-----------------------------------128 129LLVM 22130~~~~~~~131 132- The status of the C++03 implementation will be frozen after the LLVM 21 release. This means that starting in LLVM 22,133 non-critical bug fixes may not be back-ported to C++03, including LWG issues. C++03 is a legacy platform, where most134 projects are no longer actively maintained. To reduce the amount of fixes required to keep such legacy projects135 compiling with up-to-date toolchains, libc++ will aim to freeze the status of the headers in C++03 mode to avoid136 unintended breaking changes. See https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc for more details.137 138 If you are using C++03 in your project, you should consider moving to a newer version of the Standard to get the most139 out of libc++.140 141 142ABI Affecting Changes143---------------------144 145- When using GCC, the ``std`` namespace is now annotated with ``[[gnu::visibility("default")]]``. This may cause more146 symbols to be exported from shared libraries when building with ``-fvisibility=hidden``. This also fixes RTTI147 comparison between shared libraries, since all RTTI has the correct visibility now. There is no behaviour change on148 Clang.149 150- 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).151 In addition, the layout of a user-defined type that:152 153 - 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``, and154 - passes an empty allocator, comparator or hasher type to that container, and155 - has a member of that same empty allocator, comparator or hasher type inside the enclosing struct, and156 - that member is either marked with ``[[no_unique_address]]`` or optimized out via the EBO (empty base optimization) technique157 158 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.159 160 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.161 162 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.163 164 For more details see https://llvm.org/PR154146.165 166Build System Changes167--------------------168 169- TODO170