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 130Deprecations and Removals 131------------------------- 132 133- The C++20 synchronization library (``<barrier>``, ``<latch>``, ``std::atomic::wait``, etc.) has been deprecated 134 in language modes prior to C++20. If you are using these features prior to C++20, please update to ``-std=c++20``. 135 In LLVM 20, the C++20 synchronization library will be removed entirely in language modes prior to C++20. 136 137- ``_LIBCPP_DISABLE_NODISCARD_EXT`` has been removed. ``[[nodiscard]]`` applications are now unconditional. 138 This decision is based on LEWGs discussion on `P3122 <https://wg21.link/P3122>`_ and `P3162 <https://wg21.link/P3162>`_ 139 to not use ``[[nodiscard]]`` in the standard. 140 141- The ``LIBCXX_ENABLE_ASSERTIONS`` CMake variable that was used to enable the safe mode has been deprecated and setting 142 it triggers an error; use the ``LIBCXX_HARDENING_MODE`` CMake variable with the value ``extensive`` instead. Similarly, 143 the ``_LIBCPP_ENABLE_ASSERTIONS`` macro has been deprecated (setting it to ``1`` still enables the extensive mode in 144 the LLVM 19 release while also issuing a deprecation warning). See :ref:`the hardening documentation 145 <using-hardening-modes>` for more details. 146 147- The base template for ``std::char_traits`` has been removed in LLVM 19. If you are using ``std::char_traits`` with 148 types other than ``char``, ``wchar_t``, ``char8_t``, ``char16_t``, ``char32_t`` or a custom character type for which you 149 specialized ``std::char_traits``, your code will stop working. The Standard does not mandate that a base template is 150 provided, and such a base template is bound to be incorrect for some types, which could currently cause unexpected behavior 151 while going undetected. 152 153- The ``_LIBCPP_ENABLE_NARROWING_CONVERSIONS_IN_VARIANT`` macro that changed the behavior for narrowing conversions 154 in ``std::variant`` has been removed in LLVM 19. 155 156- The ``_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS`` and ``_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION`` 157 macros have been removed in LLVM 19. 158 159- The ``_LIBCPP_ENABLE_CXX17_REMOVED_FEATURES`` and ``_LIBCPP_ENABLE_CXX20_REMOVED_FEATURES`` macros have 160 been removed in LLVM 19. C++17 and C++20 removed features can still be re-enabled individually. 161 162- The ``_LIBCPP_INLINE_VISIBILITY`` and ``_VSTD`` macros have been removed in LLVM 19. 163 164- The ``_LIBCPP_ATOMIC_ONLY_USE_BUILTINS`` configuration option has been removed in LLVM 19. This should not affect 165 many users, except perhaps users using the library with ``-ffreestanding`` with a toolchain where compiler-rt or 166 libatomic is not available. If you are one such user, please reach out to the libc++ developers so we can collaborate 167 on a path for supporting atomics properly on freestanding platforms. 168 169- LWG3430 disallow implicit conversion of the source arguments to ``std::filesystem::path`` when 170 constructing ``std::basic_*fstream``. This effectively removes the possibility to directly construct 171 a ``std::basic_*fstream`` from a ``std::basic_string_view``, a input-iterator or a C-string, instead 172 you can construct a temporary ``std::basic_string``. This change has been applied to C++17 and later. 173 174- The ``_LIBCPP_DISABLE_ADDITIONAL_DIAGNOSTICS`` macro has been removed and is not honored anymore. Additional 175 warnings provided by libc++ as a matter of QoI will now be provided unconditionally. 176 177- libc++ no longer supports ``std::allocator<const T>`` and containers of ``const``-qualified element type, such 178 as ``std::vector<const T>`` and ``std::list<const T>``. This used to be supported as an undocumented extension. 179 If you were using ``std::vector<const T>``, replace it with ``std::vector<T>`` instead. The 180 ``_LIBCPP_ENABLE_REMOVED_ALLOCATOR_CONST`` macro can be defined to temporarily re-enable this extension. 181 to temporarily re-enable this extension to make it easier to update user code 182 This macro will be honored for one released and ignored starting in LLVM 20. 183 To assist with the clean-up process, consider running your code through Clang Tidy, with 184 `std-allocator-const <https://clang.llvm.org/extra/clang-tidy/checks/portability/std-allocator-const.html>`_ 185 enabled. 186 187- When configuring libc++ with localization or threads disabled, the library no longer emits an error when 188 trying to ``#include <locale>`` and other such headers. Instead, those headers have no content. This is 189 consistent with the behavior for all other libc++ carve-outs like filesystem, wide characters, a source 190 of randomness, and others. Users that were checking whether including a header would fail (e.g. via a script 191 or CMake's ``try_compile`` will experience a change in behavior). 192 193- libc++ no longer supports relational comparison for ``std::chrono::weekday``. The relational comparison operators were 194 provided as an undocumented extension. If you were using relational comparison on ``std::chrono::weekday``, compare 195 the results of ``c_encoding()`` or ``iso_encoding()`` instead. The 196 ``_LIBCPP_ENABLE_REMOVED_WEEKDAY_RELATIONAL_OPERATORS`` macro can be defined to temporarily re-enable this extension. 197 This macro will be honored for one release and ignored starting in LLVM 20. 198 199- The operators in the ``rel_ops`` namespace have been deprecated. The deprecation is part of the paper 200 P0768R1 "Library Support for the Spaceship (Comparison) Operator". 201 202Upcoming Deprecations and Removals 203---------------------------------- 204 205LLVM 20 206~~~~~~~ 207 208- The ``LIBCXX_ENABLE_ASSERTIONS`` CMake variable and the ``_LIBCPP_ENABLE_ASSERTIONS`` macro that were used to enable 209 the safe mode will be removed in LLVM 20. 210 211- The C++20 synchronization library will be removed entirely in language modes prior to C++20 in LLVM 20. 212 213- The relational operators for ``std::chrono::weekday`` will be removed entirely, and the 214 ``_LIBCPP_ENABLE_REMOVED_WEEKDAY_RELATIONAL_OPERATORS`` macro that was used to re-enable this extension will be 215 ignored in LLVM 20. 216 217- The ``_LIBCPP_ENABLE_REMOVED_ALLOCATOR_CONST`` macro will no longer have an effect. 218 219 220LLVM 21 221~~~~~~~ 222 223- 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 224 to C++03, including LWG issues. C++03 is a legacy platform, where most projects are no longer actively maintained. To 225 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. 226 See https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc for more details. 227 228 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++. 229 230 231ABI Affecting Changes 232--------------------- 233 234- The optional POSIX macro ``ENODATA`` has been deprecated in C++ and POSIX 2017. The 235 ``random_device`` could throw a ``system_error`` with this value. It now 236 throws ``ENOMSG``. 237 238 239Build System Changes 240-------------------- 241 242- The ``LIBCXX_EXECUTOR`` and ``LIBCXXABI_EXECUTOR`` CMake variables have been removed. Please 243 set ``LIBCXX_TEST_PARAMS`` to ``executor=<...>`` instead. 244 245- The CMake variable ``LIBCXX_ENABLE_CLANG_TIDY`` has been removed. The build system has been changed 246 to automatically detect the presence of ``clang-tidy`` and the required ``Clang`` libraries. 247 248- The CMake options ``LIBCXX_INSTALL_MODULES`` now defaults to ``ON``. 249 250- The CMake options ``LIBCXX_BENCHMARK_NATIVE_STDLIB`` and ``LIBCXX_BENCHMARK_NATIVE_GCC_TOOLCHAIN`` have 251 been removed. To benchmark the native standard library, configure the test suite against the native 252 standard library directly instead. 253