1=========================================== 2Libc++ 19.0.0 (In-Progress) Release Notes 3=========================================== 4 5.. contents:: 6 :local: 7 :depth: 2 8 9Written by the `Libc++ Team <https://libcxx.llvm.org>`_ 10 11.. warning:: 12 13 These are in-progress notes for the upcoming libc++ 19.0.0 release. 14 Release notes for previous releases can be found on 15 `the Download Page <https://releases.llvm.org/download.html>`_. 16 17Introduction 18============ 19 20This document contains the release notes for the libc++ C++ Standard Library, 21part of the LLVM Compiler Infrastructure, release 19.0.0. Here we describe the 22status of libc++ in some detail, including major improvements from the previous 23release and new feature work. For the general LLVM release notes, see `the LLVM 24documentation <https://llvm.org/docs/ReleaseNotes.html>`_. All LLVM releases may 25be downloaded from the `LLVM releases web site <https://llvm.org/releases/>`_. 26 27For more information about libc++, please see the `Libc++ Web Site 28<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 the 31main Libc++ web page, this document applies to the *next* release, not 32the current one. To see the release notes for a specific release, please 33see the `releases page <https://llvm.org/releases/>`_. 34 35What's New in Libc++ 19.0.0? 36============================== 37 38The main focus of the libc++ team has been to implement new C++20, C++23, 39and C++26 features. 40 41Experimental support for the time zone database has progressed. 42 43Work on the ranges support has progressed. 44 45Work on the experimental C++17 Parallel STL has progressed. See 46:ref:`pstl-status` for the current status. 47 48Work on the C++17 mathematical special functions has started. See 49`this issue <https://github.com/llvm/llvm-project/issues/99939>`__ 50for the current status. 51 52Implemented Papers 53------------------ 54 55- P1132R8 - ``out_ptr`` - a scalable output pointer abstraction 56- P1614R2 - The Mothership has Landed 57- P2637R3 - Member ``visit`` 58- P2652R2 - Disallow User Specialization of ``allocator_traits`` 59- P2819R2 - Add ``tuple`` protocol to ``complex`` 60- P2495R3 - Interfacing ``stringstream``\s with ``string_view`` 61- P2867R2 - Remove Deprecated ``strstream``\s From C++26 62- P2872R3 - Remove ``wstring_convert`` From C++26 63- P3142R0 - Printing Blank Lines with ``println`` (as DR against C++23) 64- P2944R3 - Comparisons for ``reference_wrapper`` (comparison operators for ``reference_wrapper`` only) 65- P2591R5 - Concatenation of strings and string views 66- P2968R2 - Make ``std::ignore`` a first-class object 67- P2997R1 - Removing the common reference requirement from the indirectly invocable concepts (as DR against C++20) 68- P2302R4 - ``std::ranges::contains`` 69- P1659R3 - ``std::ranges::starts_with`` and ``std::ranges::ends_with`` 70- P3029R1 - Better ``mdspan``'s CTAD 71- P2387R3 - Pipe support for user-defined range adaptors 72- P2713R1 - Escaping improvements in ``std::format`` 73- P2231R1 - Missing ``constexpr`` in ``std::optional`` and ``std::variant`` 74- P0019R8 - ``std::atomic_ref`` 75- P2389R2 - Alias template ``dims`` for the ``extents`` of ``mdspan`` 76- P1223R5 - ``ranges::find_last()``, ``ranges::find_last_if()``, and ``ranges::find_last_if_not()`` 77- P2602R2 - Poison Pills are Too Toxic 78- P1981R0 - Rename ``leap`` to ``leap_second`` 79- P1982R0 - Rename ``link`` to ``time_zone_link`` 80- P2602R2 - Poison Pills are Too Toxic (as DR against C++20) 81 82 83Improvements and New Features 84----------------------------- 85 86- The performance of growing ``std::vector`` has been improved for trivially relocatable types. 87 88- A lot of types are considered trivially relocatable now, including ``std::vector`` and ``std::string``. 89 90- The performance of ``std::ranges::fill`` and ``std::ranges::fill_n`` has been improved for ``std::vector<bool>::iterator``\s, 91 resulting in a performance increase of up to 1400x. 92 93- The ``std::mismatch`` algorithm has been optimized for integral types, which can lead up to 40x performance 94 improvements. 95 96- The ``std::ranges::minmax`` algorithm has been optimized for integral types, resulting in a performance increase of 97 up to 100x. 98 99- The ``std::set_intersection`` and ``std::ranges::set_intersection`` algorithms have been optimized to fast-forward over 100 contiguous ranges of non-matching values, reducing the number of comparisons from linear to 101 logarithmic growth with the number of elements in best-case scenarios. 102 103- The ``_LIBCPP_ENABLE_CXX26_REMOVED_STRSTREAM`` macro has been added to make the declarations in ``<strstream>`` available. 104 105- The ``_LIBCPP_ENABLE_CXX26_REMOVED_WSTRING_CONVERT`` macro has been added to make the declarations in ``<locale>`` 106 available. 107 108- The formatting library is updated to Unicode 15.1.0. 109 110- ``std::ignore``\s ``const __ignore_t& operator=(_Tp&&) const`` was changed to 111 ``const __ignore_type& operator=(const _Tp&) const noexcept`` for all language versions. 112 113- Vendors can now configure the ABI so that ``string`` and ``vector`` will use bounded iterators when hardening is 114 enabled. Note that checks for iterator invalidation are currently not supported -- any accesses made through an 115 invalidated bounded iterator will still result in undefined behavior (bounded iterators follow the normal invalidation 116 rules of the associated container). ``string`` bounded iterators use the logical size of the container (``index 117 < str.size()``) whereas ``vector`` bounded iterators use the "physical" size of the container (``index 118 < vec.capacity()``) which is a less strict check; refer to the implementation for further details. 119 120 Bounded iterators can be enabled via the ``_LIBCPP_ABI_BOUNDED_ITERATORS_IN_STRING`` ABI macro for ``string`` and via 121 the ``_LIBCPP_ABI_BOUNDED_ITERATORS_IN_VECTOR`` ABI macro for ``vector``; note that checks will only be performed if 122 the hardening mode is set to ``fast`` or above (i.e., no checking is performed in the unchecked mode, even if bounded 123 iterators are enabled in the ABI configuration). 124 125 Note: bounded iterators currently are not supported for ``vector<bool>``. 126 127- In C++23 and C++26 the number of transitive includes in several headers has been reduced, improving the compilation speed. 128 129- ``std::stable_sort`` uses radix sort for integral types now, which can improve the performance up to 10 times, depending 130 on type of sorted elements and the initial state of the sorted array. 131 132Deprecations and Removals 133------------------------- 134 135- The C++20 synchronization library (``<barrier>``, ``<latch>``, ``std::atomic::wait``, etc.) has been deprecated 136 in language modes prior to C++20. If you are using these features prior to C++20, please update to ``-std=c++20``. 137 In LLVM 20, the C++20 synchronization library will be removed entirely in language modes prior to C++20. 138 139- ``_LIBCPP_DISABLE_NODISCARD_EXT`` has been removed. ``[[nodiscard]]`` applications are now unconditional. 140 This decision is based on LEWGs discussion on `P3122 <https://wg21.link/P3122>`_ and `P3162 <https://wg21.link/P3162>`_ 141 to not use ``[[nodiscard]]`` in the standard. 142 143- The ``LIBCXX_ENABLE_ASSERTIONS`` CMake variable that was used to enable the safe mode has been deprecated and setting 144 it triggers an error; use the ``LIBCXX_HARDENING_MODE`` CMake variable with the value ``extensive`` instead. Similarly, 145 the ``_LIBCPP_ENABLE_ASSERTIONS`` macro has been deprecated (setting it to ``1`` still enables the extensive mode in 146 the LLVM 19 release while also issuing a deprecation warning). See :ref:`the hardening documentation 147 <using-hardening-modes>` for more details. 148 149- The base template for ``std::char_traits`` has been removed in LLVM 19. If you are using ``std::char_traits`` with 150 types other than ``char``, ``wchar_t``, ``char8_t``, ``char16_t``, ``char32_t`` or a custom character type for which you 151 specialized ``std::char_traits``, your code will stop working. The Standard does not mandate that a base template is 152 provided, and such a base template is bound to be incorrect for some types, which could currently cause unexpected behavior 153 while going undetected. 154 155- The ``_LIBCPP_ENABLE_NARROWING_CONVERSIONS_IN_VARIANT`` macro that changed the behavior for narrowing conversions 156 in ``std::variant`` has been removed in LLVM 19. 157 158- The ``_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS`` and ``_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION`` 159 macros have been removed in LLVM 19. 160 161- The ``_LIBCPP_ENABLE_CXX17_REMOVED_FEATURES`` and ``_LIBCPP_ENABLE_CXX20_REMOVED_FEATURES`` macros have 162 been removed in LLVM 19. C++17 and C++20 removed features can still be re-enabled individually. 163 164- The ``_LIBCPP_INLINE_VISIBILITY`` and ``_VSTD`` macros have been removed in LLVM 19. 165 166- The ``_LIBCPP_ATOMIC_ONLY_USE_BUILTINS`` configuration option has been removed in LLVM 19. This should not affect 167 many users, except perhaps users using the library with ``-ffreestanding`` with a toolchain where compiler-rt or 168 libatomic is not available. If you are one such user, please reach out to the libc++ developers so we can collaborate 169 on a path for supporting atomics properly on freestanding platforms. 170 171- LWG3430 disallow implicit conversion of the source arguments to ``std::filesystem::path`` when 172 constructing ``std::basic_*fstream``. This effectively removes the possibility to directly construct 173 a ``std::basic_*fstream`` from a ``std::basic_string_view``, a input-iterator or a C-string, instead 174 you can construct a temporary ``std::basic_string``. This change has been applied to C++17 and later. 175 176- The ``_LIBCPP_DISABLE_ADDITIONAL_DIAGNOSTICS`` macro has been removed and is not honored anymore. Additional 177 warnings provided by libc++ as a matter of QoI will now be provided unconditionally. 178 179- libc++ no longer supports ``std::allocator<const T>`` and containers of ``const``-qualified element type, such 180 as ``std::vector<const T>`` and ``std::list<const T>``. This used to be supported as an undocumented extension. 181 If you were using ``std::vector<const T>``, replace it with ``std::vector<T>`` instead. The 182 ``_LIBCPP_ENABLE_REMOVED_ALLOCATOR_CONST`` macro can be defined to temporarily re-enable this extension. 183 to temporarily re-enable this extension to make it easier to update user code 184 This macro will be honored for one released and ignored starting in LLVM 20. 185 To assist with the clean-up process, consider running your code through Clang Tidy, with 186 `std-allocator-const <https://clang.llvm.org/extra/clang-tidy/checks/portability/std-allocator-const.html>`_ 187 enabled. 188 189- When configuring libc++ with localization or threads disabled, the library no longer emits an error when 190 trying to ``#include <locale>`` and other such headers. Instead, those headers have no content. This is 191 consistent with the behavior for all other libc++ carve-outs like filesystem, wide characters, a source 192 of randomness, and others. Users that were checking whether including a header would fail (e.g. via a script 193 or CMake's ``try_compile`` will experience a change in behavior). 194 195- libc++ no longer supports relational comparison for ``std::chrono::weekday``. The relational comparison operators were 196 provided as an undocumented extension. If you were using relational comparison on ``std::chrono::weekday``, compare 197 the results of ``c_encoding()`` or ``iso_encoding()`` instead. The 198 ``_LIBCPP_ENABLE_REMOVED_WEEKDAY_RELATIONAL_OPERATORS`` macro can be defined to temporarily re-enable this extension. 199 This macro will be honored for one release and ignored starting in LLVM 20. 200 201- The operators in the ``rel_ops`` namespace have been deprecated. The deprecation is part of the paper 202 P0768R1 "Library Support for the Spaceship (Comparison) Operator". 203 204Upcoming Deprecations and Removals 205---------------------------------- 206 207LLVM 20 208~~~~~~~ 209 210- The ``LIBCXX_ENABLE_ASSERTIONS`` CMake variable and the ``_LIBCPP_ENABLE_ASSERTIONS`` macro that were used to enable 211 the safe mode will be removed in LLVM 20. 212 213- The C++20 synchronization library will be removed entirely in language modes prior to C++20 in LLVM 20. 214 215- The relational operators for ``std::chrono::weekday`` will be removed entirely, and the 216 ``_LIBCPP_ENABLE_REMOVED_WEEKDAY_RELATIONAL_OPERATORS`` macro that was used to re-enable this extension will be 217 ignored in LLVM 20. 218 219- The ``_LIBCPP_ENABLE_REMOVED_ALLOCATOR_CONST`` macro will no longer have an effect. 220 221 222LLVM 21 223~~~~~~~ 224 225- 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 226 to C++03, including LWG issues. C++03 is a legacy platform, where most projects are no longer actively maintained. To 227 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. 228 See https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc for more details. 229 230 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++. 231 232 233ABI Affecting Changes 234--------------------- 235 236- The optional POSIX macro ``ENODATA`` has been deprecated in C++ and POSIX 2017. The 237 ``random_device`` could throw a ``system_error`` with this value. It now 238 throws ``ENOMSG``. 239 240 241Build System Changes 242-------------------- 243 244- The ``LIBCXX_EXECUTOR`` and ``LIBCXXABI_EXECUTOR`` CMake variables have been removed. Please 245 set ``LIBCXX_TEST_PARAMS`` to ``executor=<...>`` instead. 246 247- The CMake variable ``LIBCXX_ENABLE_CLANG_TIDY`` has been removed. The build system has been changed 248 to automatically detect the presence of ``clang-tidy`` and the required ``Clang`` libraries. 249 250- The CMake options ``LIBCXX_INSTALL_MODULES`` now defaults to ``ON``. 251 252- The CMake options ``LIBCXX_BENCHMARK_NATIVE_STDLIB`` and ``LIBCXX_BENCHMARK_NATIVE_GCC_TOOLCHAIN`` have 253 been removed. To benchmark the native standard library, configure the test suite against the native 254 standard library directly instead. 255