176d0caaeSpatrick========================================= 2*4bdff4beSrobertLibc++ 16.0.0 (In-Progress) Release Notes 376d0caaeSpatrick========================================= 446035553Spatrick 546035553Spatrick.. contents:: 646035553Spatrick :local: 746035553Spatrick :depth: 2 846035553Spatrick 946035553SpatrickWritten by the `Libc++ Team <https://libcxx.llvm.org>`_ 1046035553Spatrick 1176d0caaeSpatrick.. warning:: 1276d0caaeSpatrick 13*4bdff4beSrobert These are in-progress notes for the upcoming libc++ 16 release. 1476d0caaeSpatrick Release notes for previous releases can be found on 1576d0caaeSpatrick `the Download Page <https://releases.llvm.org/download.html>`_. 1676d0caaeSpatrick 1746035553SpatrickIntroduction 1846035553Spatrick============ 1946035553Spatrick 2046035553SpatrickThis document contains the release notes for the libc++ C++ Standard Library, 21*4bdff4beSrobertpart of the LLVM Compiler Infrastructure, release 16.0.0. Here we describe the 2246035553Spatrickstatus of libc++ in some detail, including major improvements from the previous 2346035553Spatrickrelease and new feature work. For the general LLVM release notes, see `the LLVM 2446035553Spatrickdocumentation <https://llvm.org/docs/ReleaseNotes.html>`_. All LLVM releases may 2546035553Spatrickbe downloaded from the `LLVM releases web site <https://llvm.org/releases/>`_. 2646035553Spatrick 2746035553SpatrickFor more information about libc++, please see the `Libc++ Web Site 2846035553Spatrick<https://libcxx.llvm.org>`_ or the `LLVM Web Site <https://llvm.org>`_. 2946035553Spatrick 3076d0caaeSpatrickNote that if you are reading this file from a Git checkout or the 3176d0caaeSpatrickmain Libc++ web page, this document applies to the *next* release, not 3276d0caaeSpatrickthe current one. To see the release notes for a specific release, please 3376d0caaeSpatricksee the `releases page <https://llvm.org/releases/>`_. 3476d0caaeSpatrick 35*4bdff4beSrobertWhat's New in Libc++ 16.0.0? 3646035553Spatrick============================ 3746035553Spatrick 38*4bdff4beSrobertThe main focus of the libc++ team has been to implement new C++20 and C++23 39*4bdff4beSrobertfeatures. 4076d0caaeSpatrick 41*4bdff4beSrobertThe C++20 format library has improved but it not yet considered stable. The 42*4bdff4beSrobertmain improvements are additional formatters for the chrono calendar types. Work 43*4bdff4beSroberton formatting ranges has started. 4446035553Spatrick 45*4bdff4beSrobertThe C++20 ranges library has been completed and is no longer experimental (with 46*4bdff4beSrobertthe exception of `ranges::join_view` which is still marked as experimental 47*4bdff4beSrobertbecause it is about to undergo an ABI-breaking change in the Standard due to 48*4bdff4beSrobert`D2770 <https://isocpp.org/files/papers/D2770R0.html>`_). Work on C++23 ranges 49*4bdff4beSroberthas started. 5076d0caaeSpatrick 51*4bdff4beSrobertThe C++20 spaceship operator has been added to more types, the work is still 52*4bdff4beSrobertongoing. 5376d0caaeSpatrick 54*4bdff4beSrobert`D139235 <https://reviews.llvm.org/D139235>`_ made ``copy`` and ``move`` 55*4bdff4beSrobertalgorithms and their variations (``copy_backward``, etc.) apply optimizations 56*4bdff4beSrobertfor trivial types more often. This has the potential to expose bugs in code 57*4bdff4beSrobertusing these algorithms that currently relies on undefined behavior (this 58*4bdff4beSrobertincludes indirect usage -- for example, these algorithms are used in the 59*4bdff4beSrobertimplementation of some standard containers). This change also made the 60*4bdff4beSrobertalgorithms check the given iterator types for conformance more strictly. 61*4bdff4beSrobert 62*4bdff4beSrobertImplemented Papers 63*4bdff4beSrobert------------------ 64*4bdff4beSrobert- P2499R0 - ``string_view`` range constructor should be ``explicit`` 65*4bdff4beSrobert- P2417R2 - A more constexpr bitset 66*4bdff4beSrobert- P2445R1 - ``std::forward_like`` 67*4bdff4beSrobert- P2273R3 - Making ``std::unique_ptr`` constexpr 68*4bdff4beSrobert- P0591R4 - Utility functions to implement uses-allocator construction 69*4bdff4beSrobert- P2291R3 - Add Constexpr Modifiers to Functions ``to_chars`` and 70*4bdff4beSrobert ``from_chars`` for Integral Types in ``<charconv>`` Header 71*4bdff4beSrobert- P0220R1 - Adopt Library Fundamentals V1 TS Components for C++17 72*4bdff4beSrobert- P0482R6 - char8_t: A type for UTF-8 characters and strings 73*4bdff4beSrobert- P2438R2 - ``std::string::substr() &&`` 74*4bdff4beSrobert- P0600R1 - ``nodiscard`` in the library 75*4bdff4beSrobert- P0339R6 - ``polymorphic_allocator<>`` as a vocabulary type 76*4bdff4beSrobert- P1169R4 - ``static operator()`` 77*4bdff4beSrobert- P0415R1 - ``constexpr`` for ``std::complex`` 78*4bdff4beSrobert- P1208R6 - ``std::source_location`` 79*4bdff4beSrobert- P0323R12 - ``std::expected`` 80*4bdff4beSrobert- P1035R7 - Input Range Adaptors 81*4bdff4beSrobert- P2325R3 - Views should not be required to be default constructible 82*4bdff4beSrobert- P2446R2 - ``views::as_rvalue`` 83*4bdff4beSrobert- P1020R1 - Smart pointer creation with default initialization 84*4bdff4beSrobert- P2210R2 - Superior String Splitting 85*4bdff4beSrobert- P2286R8 - Formatting Ranges 86*4bdff4beSrobert 87*4bdff4beSrobertImprovements and New Features 88*4bdff4beSrobert----------------------------- 89*4bdff4beSrobert- Declarations of ``std::c8rtomb()`` and ``std::mbrtoc8()`` from P0482R6 are 90*4bdff4beSrobert now provided when implementations in the global namespace are provided by 91*4bdff4beSrobert the C library. 92*4bdff4beSrobert- Implemented ``<memory_resource>`` header from C++17 93*4bdff4beSrobert- The ``ranges`` versions of ``copy``, ``move``, ``copy_backward`` and ``move_backward`` are now also optimized for 94*4bdff4beSrobert ``std::deque<>::iterator``, which can lead to up to 20x performance improvements on certain algorithms. 95*4bdff4beSrobert- The ``std`` and ``ranges`` versions of ``copy``, ``move``, ``copy_backward`` and ``move_backward`` are now also 96*4bdff4beSrobert optimized for ``join_view::iterator``, which can lead to up to 20x performance improvements on certain combinations of 97*4bdff4beSrobert iterators and algorithms. 98*4bdff4beSrobert 99*4bdff4beSrobertDeprecations and Removals 100*4bdff4beSrobert------------------------- 101*4bdff4beSrobert- ``unary_function`` and ``binary_function`` are no longer provided in C++17 and newer Standard modes. 102*4bdff4beSrobert They can be re-enabled with ``_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION``. 103*4bdff4beSrobert 104*4bdff4beSrobert- Several incidental transitive includes have been removed from libc++. Those 105*4bdff4beSrobert includes are removed based on the language version used. Incidental transitive 106*4bdff4beSrobert inclusions of the following headers have been removed: 107*4bdff4beSrobert 108*4bdff4beSrobert - C++11, C++14, C++17, and C++20: ``chrono`` 109*4bdff4beSrobert - C++2b: ``algorithm``, ``array``, ``atomic``, ``bit``, ``chrono``, 110*4bdff4beSrobert ``climits``, ``cmath``, ``compare``, ``concepts``, ``cstdarg``, ``cstddef``, 111*4bdff4beSrobert ``cstdint``, ``cstdlib``, ``cstring``, ``ctime``, ``exception``, 112*4bdff4beSrobert ``functional``, ``initializer_list``, ``iosfwd``, ``iterator``, ``limits``, 113*4bdff4beSrobert ``memory``, ``new``, ``numeric``, ``optional``, ``ratio``, ``stdexcept``, 114*4bdff4beSrobert ``string``, ``tuple``, ``type_traits``, ``typeinfo``, ``unordered_map``, 115*4bdff4beSrobert ``utility``, ``variant``, ``vector``. 116*4bdff4beSrobert 117*4bdff4beSrobert Users can also remove all incidental transitive includes by defining 118*4bdff4beSrobert ``_LIBCPP_REMOVE_TRANSITIVE_INCLUDES`` regardless of the language version 119*4bdff4beSrobert in use. Note that in the future, libc++ reserves the right to remove 120*4bdff4beSrobert incidental transitive includes more aggressively, in particular regardless 121*4bdff4beSrobert of the language version in use. 122*4bdff4beSrobert 123*4bdff4beSrobert- The legacy testing system for libc++, libc++abi, and libunwind has been removed. 124*4bdff4beSrobert All known clients have been migrated to the new configuration system, but please 125*4bdff4beSrobert reach out to the libc++ developers if you find something missing in the new 126*4bdff4beSrobert configuration system. 127*4bdff4beSrobert 128*4bdff4beSrobert- The functions ``to_chars`` and ``from_chars`` for integral types are 129*4bdff4beSrobert available starting with C++17. Libc++ offered these functions in C++11 and 130*4bdff4beSrobert C++14 as an undocumented extension. This extension makes it hard to implement 131*4bdff4beSrobert the C++23 paper that makes these functions ``constexpr``, therefore the 132*4bdff4beSrobert extension has been removed. 133*4bdff4beSrobert 134*4bdff4beSrobert- The ``_LIBCPP_ENABLE_CXX03_FUNCTION`` macro that allowed re-enabling the now-deprecated C++03 implementation of 135*4bdff4beSrobert ``std::function`` has been removed. Users who need to use ``std::function`` should switch to C++11 and above. 136*4bdff4beSrobert 137*4bdff4beSrobert- The contents of ``<experimental/memory_resource>`` are now deprecated since libc++ ships ``<memory_resource>`` now. 138*4bdff4beSrobert Please migrate to ``<memory_resource>`` instead. Per libc++'s TS deprecation policy, 139*4bdff4beSrobert ``<experimental/memory_resource>`` will be removed in LLVM 18. 140*4bdff4beSrobert 141*4bdff4beSrobert- The ``_LIBCPP_DEBUG`` macro is not honored anymore, and it is an error to try to use it. Please migrate to 142*4bdff4beSrobert ``_LIBCPP_ENABLE_DEBUG_MODE`` instead. 143*4bdff4beSrobert 144*4bdff4beSrobertUpcoming Deprecations and Removals 145*4bdff4beSrobert---------------------------------- 146*4bdff4beSrobert- The base template for ``std::char_traits`` has been marked as deprecated and will be removed in LLVM 18. If 147*4bdff4beSrobert you are using ``std::char_traits`` with types other than ``char``, ``wchar_t``, ``char8_t``, ``char16_t``, 148*4bdff4beSrobert ``char32_t`` or a custom character type for which you specialized ``std::char_traits``, your code will stop 149*4bdff4beSrobert working when we remove the base template. The Standard does not mandate that a base template is provided, 150*4bdff4beSrobert and such a base template is bound to be incorrect for some types, which could currently cause unexpected 151*4bdff4beSrobert behavior while going undetected. 152*4bdff4beSrobert 153*4bdff4beSrobert- The ``_LIBCPP_AVAILABILITY_CUSTOM_VERBOSE_ABORT_PROVIDED`` macro will not be honored anymore in LLVM 18. 154*4bdff4beSrobert Please see the updated documentation about the safe libc++ mode and in particular the ``_LIBCPP_VERBOSE_ABORT`` 155*4bdff4beSrobert macro for details. 15676d0caaeSpatrick 15776d0caaeSpatrickAPI Changes 15876d0caaeSpatrick----------- 159*4bdff4beSrobert- The comparison operators on ``thread::id`` are now defined as free-standing 160*4bdff4beSrobert functions instead of as hidden friends, in conformance with the C++ standard. 161*4bdff4beSrobert Also see `issue 56187 <https://github.com/llvm/llvm-project/issues/56187>`_. 16276d0caaeSpatrick 163*4bdff4beSrobert- ``_LIBCPP_ENABLE_NODISCARD`` and ``_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17`` are no longer respected. 164*4bdff4beSrobert Any standards-required ``[[nodiscard]]`` applications in C++20 are now always enabled. Any extended applications 165*4bdff4beSrobert are now enabled by default and can be disabled by defining ``_LIBCPP_DISABLE_NODISCARD_EXT``. 16676d0caaeSpatrick 167*4bdff4beSrobert- ``_LIBCPP_VERSION`` was previously defined to e.g. ``15001`` to represent LLVM 15.0.01, but this value had been 168*4bdff4beSrobert left undocumented. Starting with LLVM 16, ``_LIBCPP_VERSION`` will contain the version of LLVM represented as 169*4bdff4beSrobert ``XXYYZZ``. In other words, ``_LIBCPP_VERSION`` is gaining a digit. This should not be an issue for existing 170*4bdff4beSrobert code, since using e.g. ``_LIBCPP_VERSION > 15000`` will still give the right answer now that ``_LIBCPP_VERSION`` 171*4bdff4beSrobert is defined as e.g. ``160000`` (with one more digit). 17276d0caaeSpatrick 173*4bdff4beSrobertABI Affecting Changes 174*4bdff4beSrobert--------------------- 175*4bdff4beSrobert- In freestanding mode, ``atomic<small enum class>`` does not contain a lock byte anymore if the platform 176*4bdff4beSrobert can implement lockfree atomics for that size. More specifically, in LLVM <= 11.0.1, an ``atomic<small enum class>`` 177*4bdff4beSrobert would not contain a lock byte. This was broken in LLVM >= 12.0.0, where it started including a lock byte despite 178*4bdff4beSrobert the platform supporting lockfree atomics for that size. Starting in LLVM 15.0.1, the ABI for these types has been 179*4bdff4beSrobert restored to what it used to be (no lock byte), which is the most efficient implementation. 18076d0caaeSpatrick 181*4bdff4beSrobert This ABI break only affects users that compile with ``-ffreestanding``, and only for ``atomic<T>`` where ``T`` 182*4bdff4beSrobert is a non-builtin type that could be lockfree on the platform. See https://llvm.org/D133377 for more details. 18376d0caaeSpatrick 184*4bdff4beSrobert- When building libc++ against newlib/picolibc, the type of ``regex_type_traits::char_class_type`` was changed to 185*4bdff4beSrobert ``uint16_t`` since all values of ``ctype_base::mask`` are taken. This is technically an ABI break, but including 186*4bdff4beSrobert ``<regex> `` has triggered a ``static_assert`` failure since libc++ 14, so it is unlikely that this causes 187*4bdff4beSrobert problems for existing users. 18876d0caaeSpatrick 189*4bdff4beSrobertBuild System Changes 190*4bdff4beSrobert-------------------- 191*4bdff4beSrobert- Support for ``libcxx``, ``libcxxabi`` and ``libunwind`` in ``LLVM_ENABLE_PROJECTS`` has officially 192*4bdff4beSrobert been removed. Instead, please build according to :ref:`these instructions <build instructions>`. 193