xref: /openbsd-src/gnu/llvm/libcxx/docs/ReleaseNotes.rst (revision 4bdff4bed0e3d54e55670334c7d0077db4170f86)
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