2019-07-18 19:51:05 +08:00
|
|
|
=========================================
|
2022-02-02 15:29:29 +08:00
|
|
|
Libc++ 15.0.0 (In-Progress) Release Notes
|
2019-07-18 19:51:05 +08:00
|
|
|
=========================================
|
2018-09-06 22:46:22 +08:00
|
|
|
|
|
|
|
|
.. contents::
|
|
|
|
|
:local:
|
|
|
|
|
:depth: 2
|
|
|
|
|
|
2018-09-10 16:57:12 +08:00
|
|
|
Written by the `Libc++ Team <https://libcxx.llvm.org>`_
|
2018-09-06 22:46:22 +08:00
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
2022-02-02 15:29:29 +08:00
|
|
|
These are in-progress notes for the upcoming libc++ 15 release.
|
2018-09-06 22:46:22 +08:00
|
|
|
Release notes for previous releases can be found on
|
2018-09-10 16:57:12 +08:00
|
|
|
`the Download Page <https://releases.llvm.org/download.html>`_.
|
2018-09-06 22:46:22 +08:00
|
|
|
|
|
|
|
|
Introduction
|
|
|
|
|
============
|
|
|
|
|
|
|
|
|
|
This document contains the release notes for the libc++ C++ Standard Library,
|
2022-02-02 15:29:29 +08:00
|
|
|
part of the LLVM Compiler Infrastructure, release 15.0.0. Here we describe the
|
2018-09-06 22:46:22 +08:00
|
|
|
status of libc++ in some detail, including major improvements from the previous
|
|
|
|
|
release and new feature work. For the general LLVM release notes, see `the LLVM
|
2018-09-10 16:57:12 +08:00
|
|
|
documentation <https://llvm.org/docs/ReleaseNotes.html>`_. All LLVM releases may
|
|
|
|
|
be downloaded from the `LLVM releases web site <https://llvm.org/releases/>`_.
|
2018-09-06 22:46:22 +08:00
|
|
|
|
|
|
|
|
For more information about libc++, please see the `Libc++ Web Site
|
2018-09-10 16:57:12 +08:00
|
|
|
<https://libcxx.llvm.org>`_ or the `LLVM Web Site <https://llvm.org>`_.
|
2018-09-06 22:46:22 +08:00
|
|
|
|
2020-01-15 17:02:56 +08:00
|
|
|
Note that if you are reading this file from a Git checkout or the
|
2018-09-06 22:46:22 +08:00
|
|
|
main Libc++ web page, this document applies to the *next* release, not
|
|
|
|
|
the current one. To see the release notes for a specific release, please
|
2018-09-10 16:57:12 +08:00
|
|
|
see the `releases page <https://llvm.org/releases/>`_.
|
2018-09-06 22:46:22 +08:00
|
|
|
|
2022-02-02 15:29:29 +08:00
|
|
|
What's New in Libc++ 15.0.0?
|
2019-07-18 19:51:05 +08:00
|
|
|
============================
|
2018-09-06 22:46:22 +08:00
|
|
|
|
|
|
|
|
New Features
|
|
|
|
|
------------
|
|
|
|
|
|
2022-03-17 05:26:26 +08:00
|
|
|
- Implemented P0627R6 (Function to mark unreachable code)
|
2021-12-30 03:11:46 +08:00
|
|
|
|
2022-03-17 05:26:26 +08:00
|
|
|
- Implemented P1165R1 (Make stateful allocator propagation more consistent for ``operator+(basic_string)``)
|
2022-02-15 01:26:02 +08:00
|
|
|
|
2021-10-27 01:12:12 +08:00
|
|
|
- Implemented P0674R1 (Support arrays in make_shared and allocate_shared)
|
|
|
|
|
|
2022-03-17 05:26:26 +08:00
|
|
|
- `pop_heap` now uses an algorithm known as "bottom-up heapsort" or
|
|
|
|
|
"heapsort with bounce" to reduce the number of comparisons, and rearranges
|
|
|
|
|
elements using move-assignment instead of `swap`.
|
2021-12-30 03:11:46 +08:00
|
|
|
|
[libc++] Add a lightweight overridable assertion handler
This patch adds a lightweight assertion handler mechanism that can be
overriden at link-time in a fashion similar to `operator new`.
This is a third take on https://llvm.org/D121123 (which allowed customizing
the assertion handler at compile-time), and https://llvm.org/D119969
(which allowed customizing the assertion handler at runtime only).
This approach is, I think, the best of all three explored approaches.
Indeed, replacing the assertion handler in user code is ergonomic,
yet we retain the ability to provide a custom assertion handler when
deploying to older platforms that don't have a default handler in
the dylib.
As-is, this patch provides a pretty good amount of backwards compatibility
with the previous debug mode:
- Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions
in their code will still get basic assertions out of the box, but
those assertions will be using the new assertion handler support.
- Code that was previously compiled with references to __libcpp_debug_function
and friends will work out-of-the-box, no changes required. This is
because we provide the same symbols in the dylib as we used to.
- Code that used to set a custom __libcpp_debug_function will stop
compiling, because we don't provide that declaration anymore. Users
will have to migrate to the new way of setting a custom assertion
handler, which is extremely easy. I suspect that pool of users is
very limited, so breaking them at compile-time is probably acceptable.
The main downside of this approach is that code being compiled with
assertions enabled but deploying to an older platform where the assertion
handler didn't exist yet will fail to compile. However users can easily
fix the problem by providing a custom assertion handler and defining
the _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro to
let the library know about the custom handler. In a way, this is
actually a feature because it avoids a load-time error that one would
otherwise get when trying to run the code on the older target.
Differential Revision: https://reviews.llvm.org/D121478
2022-03-04 06:37:03 +08:00
|
|
|
- Libc++ now supports a variety of assertions that can be turned on to help catch
|
|
|
|
|
undefined behavior in user code. This new support is now separate from the old
|
|
|
|
|
(and incomplete) Debug Mode. Vendors can select whether the library they ship
|
|
|
|
|
should include assertions or not by default. For details, see
|
|
|
|
|
:ref:`the documentation <assertions-mode>` about this new feature.
|
|
|
|
|
|
2021-10-19 01:58:31 +08:00
|
|
|
API Changes
|
|
|
|
|
-----------
|
2021-06-10 02:26:34 +08:00
|
|
|
|
2022-02-08 03:52:17 +08:00
|
|
|
- The ``_LIBCPP_ABI_UNSTABLE`` macro has been removed in favour of setting
|
|
|
|
|
``_LIBCPP_ABI_VERSION=2``. This should not have any impact on users because
|
|
|
|
|
they were not supposed to set ``_LIBCPP_ABI_UNSTABLE`` manually, however we
|
|
|
|
|
still feel that it is worth mentioning in the release notes in case some users
|
|
|
|
|
had been doing it.
|
2022-03-07 22:00:17 +08:00
|
|
|
|
2022-02-12 07:45:44 +08:00
|
|
|
- The header ``<experimental/filesystem>`` has been removed. Instead, use
|
|
|
|
|
``<filesystem>`` header. The associated macro
|
|
|
|
|
``_LIBCPP_DEPRECATED_EXPERIMENTAL_FILESYSTEM`` has also been removed.
|
2022-02-08 03:52:17 +08:00
|
|
|
|
2022-04-23 16:07:24 +08:00
|
|
|
- Some libc++ headers no longer transitively include all of:
|
|
|
|
|
- ``<algorithm>``
|
|
|
|
|
- ``<chrono>``
|
|
|
|
|
- ``<functional>``
|
|
|
|
|
- ``<utility>``
|
|
|
|
|
|
|
|
|
|
If, after updating libc++, you see compiler errors related to missing declarations
|
|
|
|
|
in namespace ``std``, it might be because one of your source files now needs to
|
|
|
|
|
include one or more of the headers listed above.
|
2022-02-24 07:09:18 +08:00
|
|
|
|
2021-12-02 08:55:26 +08:00
|
|
|
- The integer distributions ``binomial_distribution``, ``discrete_distribution``,
|
|
|
|
|
``geometric_distribution``, ``negative_binomial_distribution``, ``poisson_distribution``,
|
|
|
|
|
and ``uniform_int_distribution`` now conform to the Standard by rejecting
|
|
|
|
|
template parameter types other than ``short``, ``int``, ``long``, ``long long``,
|
|
|
|
|
(as an extension) ``__int128_t``, and the unsigned versions thereof.
|
|
|
|
|
In particular, ``uniform_int_distribution<int8_t>`` is no longer supported.
|
|
|
|
|
|
2022-03-05 07:24:18 +08:00
|
|
|
- The C++14 function ``std::quoted(const char*)`` is no longer supported in
|
|
|
|
|
C++03 or C++11 modes.
|
|
|
|
|
|
[libc++] Add a lightweight overridable assertion handler
This patch adds a lightweight assertion handler mechanism that can be
overriden at link-time in a fashion similar to `operator new`.
This is a third take on https://llvm.org/D121123 (which allowed customizing
the assertion handler at compile-time), and https://llvm.org/D119969
(which allowed customizing the assertion handler at runtime only).
This approach is, I think, the best of all three explored approaches.
Indeed, replacing the assertion handler in user code is ergonomic,
yet we retain the ability to provide a custom assertion handler when
deploying to older platforms that don't have a default handler in
the dylib.
As-is, this patch provides a pretty good amount of backwards compatibility
with the previous debug mode:
- Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions
in their code will still get basic assertions out of the box, but
those assertions will be using the new assertion handler support.
- Code that was previously compiled with references to __libcpp_debug_function
and friends will work out-of-the-box, no changes required. This is
because we provide the same symbols in the dylib as we used to.
- Code that used to set a custom __libcpp_debug_function will stop
compiling, because we don't provide that declaration anymore. Users
will have to migrate to the new way of setting a custom assertion
handler, which is extremely easy. I suspect that pool of users is
very limited, so breaking them at compile-time is probably acceptable.
The main downside of this approach is that code being compiled with
assertions enabled but deploying to an older platform where the assertion
handler didn't exist yet will fail to compile. However users can easily
fix the problem by providing a custom assertion handler and defining
the _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro to
let the library know about the custom handler. In a way, this is
actually a feature because it avoids a load-time error that one would
otherwise get when trying to run the code on the older target.
Differential Revision: https://reviews.llvm.org/D121478
2022-03-04 06:37:03 +08:00
|
|
|
- Setting a custom debug handler with ``std::__libcpp_debug_function`` is not
|
|
|
|
|
supported anymore. Please migrate to using the new support for
|
|
|
|
|
:ref:`assertions <assertions-mode>` instead.
|
|
|
|
|
|
2022-04-23 02:56:58 +08:00
|
|
|
- ``vector<bool>::const_reference``, ``vector<bool>::const_iterator::reference``
|
|
|
|
|
and ``bitset::const_reference`` are now aliases for `bool` in the unstable ABI.
|
|
|
|
|
|
2021-10-29 03:38:02 +08:00
|
|
|
ABI Changes
|
|
|
|
|
-----------
|
|
|
|
|
|
2021-09-09 00:57:58 +08:00
|
|
|
- The ``_LIBCPP_ABI_USE_CXX03_NULLPTR_EMULATION`` macro controlling whether we use an
|
|
|
|
|
emulation for ``std::nullptr_t`` in C++03 mode has been removed. After this change,
|
|
|
|
|
``_LIBCPP_ABI_USE_CXX03_NULLPTR_EMULATION`` will not be honoured anymore and there
|
|
|
|
|
will be no way to opt back into the C++03 emulation of ``std::nullptr_t``.
|
|
|
|
|
|
2022-04-25 09:45:49 +08:00
|
|
|
- On FreeBSD, NetBSD and DragonFlyBSD, ``std::random_device`` is now implemented on top of
|
|
|
|
|
``arc4random()`` instead of reading from ``/dev/urandom``. Any implementation-defined
|
|
|
|
|
token used when constructing a ``std::random_device`` will now be ignored instead of
|
|
|
|
|
interpreted as a file to read entropy from.
|
|
|
|
|
|
2021-10-19 01:58:31 +08:00
|
|
|
Build System Changes
|
|
|
|
|
--------------------
|
2022-02-09 00:38:29 +08:00
|
|
|
|
|
|
|
|
- Support for standalone builds have been entirely removed from libc++, libc++abi and
|
|
|
|
|
libunwind. Please use :ref:`these instructions <build instructions>` for building
|
|
|
|
|
libc++, libc++abi and/or libunwind.
|
2021-10-13 03:59:08 +08:00
|
|
|
|
|
|
|
|
- The ``{LIBCXX,LIBCXXABI,LIBUNWIND}_TARGET_TRIPLE``, ``{LIBCXX,LIBCXXABI,LIBUNWIND}_SYSROOT`` and
|
|
|
|
|
``{LIBCXX,LIBCXXABI,LIBUNWIND}_GCC_TOOLCHAIN`` CMake variables have been removed. Instead, please
|
|
|
|
|
use the ``CMAKE_CXX_COMPILER_TARGET``, ``CMAKE_SYSROOT`` and ``CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN``
|
|
|
|
|
variables provided by CMake.
|
2022-03-08 02:32:52 +08:00
|
|
|
|
|
|
|
|
- When building for Windows, vendors who want to avoid dll-exporting symbols from the static libc++abi
|
|
|
|
|
library should set ``LIBCXXABI_HERMETIC_STATIC_LIBRARY=ON`` when configuring CMake. The current
|
|
|
|
|
behavior, which tries to guess the correct dll-export semantics based on whether we're building
|
|
|
|
|
the libc++ shared library, will be removed in LLVM 16.
|
2022-03-15 23:17:08 +08:00
|
|
|
|
|
|
|
|
- Previously, the C++ ABI library headers would be installed inside ``<prefix>/include/c++/v1``
|
|
|
|
|
alongside the libc++ headers as part of building libc++. This is not the case anymore -- the
|
|
|
|
|
ABI library is expected to install its headers where it wants them as part of its own build.
|
|
|
|
|
Note that no action is required for most users, who build libc++ against libc++abi, since
|
|
|
|
|
libc++abi already installs its headers in the right location. However, vendors building
|
|
|
|
|
libc++ against alternate ABI libraries should make sure that their ABI library installs
|
|
|
|
|
its own headers.
|
2022-03-15 02:23:38 +08:00
|
|
|
|
|
|
|
|
- The legacy testing configuration is now deprecated and will be removed in the next release. For
|
|
|
|
|
most users, this should not have any impact. However, if you are testing libc++ in a configuration
|
|
|
|
|
or on a platform that used to be supported by the legacy testing configuration and isn't supported
|
|
|
|
|
by one of the configurations in ``libcxx/test/configs``, please reach out to the libc++ developers
|
|
|
|
|
to get your configuration supported officially.
|