36d8b449cf
We introduced an optimization to std::sort in 4eddbf9f10a6. However, that optimization led to issues where users that were passing invalid comparators to std::sort could start seeing OOB reads. This led to the revert of the std::sort optimization from the LLVM 16 release (see https://llvm.org/D146421). This patch introduces _LIBCPP_ASSERTs to the places in the algorithm where we make an assumption that the comparator will be consistent and hence avoid a bounds check based on that. If the comparator happens not to be consistent with itself, these are the places where we would incorrectly go out of bounds. This allows users that enable libc++ assertions to catch such misuse at the cost of basically a bounds check. For users that do not enable libc++ assertions (which is 99.9% of users since assertions are off by default), this is basically a no-op, and in fact the assertion will turn into a __builtin_assume, making it explicit to the compiler that it can rely on the fact that we're not going out of bounds. I think this patch strikes the right balance. Folks that want absolute performance will get what they want, since it is a precondition for the comparator to be consistent, so the bounds checks are technically not mandatory. Folks who want more safety *already* need to be enabling libc++ assertions to catch other types of bugs (like operator[] OOB), so this solution should also work for them. I do think we have a lot of work towards popularizing the use of libc++ assertions and integrating it better so that users don't have to know about the obscure _LIBCPP_ENABLE_ASSERTIONS macro to enable them, but that's a separate concern. rdar://106897934 Differential Revision: https://reviews.llvm.org/D147089
131 lines
6.7 KiB
ReStructuredText
131 lines
6.7 KiB
ReStructuredText
=========================================
|
|
Libc++ 17.0.0 (In-Progress) Release Notes
|
|
=========================================
|
|
|
|
.. contents::
|
|
:local:
|
|
:depth: 2
|
|
|
|
Written by the `Libc++ Team <https://libcxx.llvm.org>`_
|
|
|
|
.. warning::
|
|
|
|
These are in-progress notes for the upcoming libc++ 17 release.
|
|
Release notes for previous releases can be found on
|
|
`the Download Page <https://releases.llvm.org/download.html>`_.
|
|
|
|
Introduction
|
|
============
|
|
|
|
This document contains the release notes for the libc++ C++ Standard Library,
|
|
part of the LLVM Compiler Infrastructure, release 17.0.0. Here we describe the
|
|
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
|
|
documentation <https://llvm.org/docs/ReleaseNotes.html>`_. All LLVM releases may
|
|
be downloaded from the `LLVM releases web site <https://llvm.org/releases/>`_.
|
|
|
|
For more information about libc++, please see the `Libc++ Web Site
|
|
<https://libcxx.llvm.org>`_ or the `LLVM Web Site <https://llvm.org>`_.
|
|
|
|
Note that if you are reading this file from a Git checkout or the
|
|
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
|
|
see the `releases page <https://llvm.org/releases/>`_.
|
|
|
|
What's New in Libc++ 17.0.0?
|
|
============================
|
|
|
|
Implemented Papers
|
|
------------------
|
|
- P2520R0 - ``move_iterator<T*>`` should be a random access iterator
|
|
- P1328R1 - ``constexpr type_info::operator==()``
|
|
- P1413R3 - Formatting ``thread::id`` (the ``stacktrace`` is not done yet)
|
|
- P2675R1 - ``format``'s width estimation is too approximate and not forward compatible
|
|
|
|
Improvements and New Features
|
|
-----------------------------
|
|
- ``std::equal`` and ``std::ranges::equal`` are now forwarding to ``std::memcmp`` for integral types and pointers,
|
|
which can lead up to 40x performance improvements.
|
|
|
|
- ``std::string_view`` now provides iterators that check for out-of-bounds accesses when the safe
|
|
libc++ mode is enabled.
|
|
|
|
- The performance of ``dynamic_cast`` on its hot paths is greatly improved and is as efficient as the
|
|
``libsupc++`` implementation. Note that the performance improvements are shipped in ``libcxxabi``.
|
|
|
|
- `D122780 <https://reviews.llvm.org/D122780>`_ Improved the performance of ``std::sort`` and ``std::ranges::sort``
|
|
by up to 50% for arithmetic types and by approximately 10% for other types.
|
|
|
|
Deprecations and Removals
|
|
-------------------------
|
|
|
|
- The ``<experimental/coroutine>`` header has been removed in this release. The ``<coroutine>`` header
|
|
has been shipping since LLVM 14, so the Coroutines TS implementation is being removed per our policy
|
|
for removing TSes.
|
|
|
|
- Several incidental transitive includes have been removed from libc++. Those
|
|
includes are removed based on the language version used. Incidental transitive
|
|
inclusions of the following headers have been removed:
|
|
|
|
- C++2b: ``atomic``, ``bit``, ``cstdint``, ``cstdlib``, ``cstring``, ``initializer_list``, ``limits``, ``new``,
|
|
``stdexcept``, ``system_error``, ``type_traits``, ``typeinfo``
|
|
|
|
- ``<algorithm>`` no longer includes ``<chrono>`` in any C++ version (it was prevously included in C++17 and earlier).
|
|
|
|
- ``<string>`` no longer includes ``<vector>`` in any C++ version (it was prevously included in C++20 and earlier).
|
|
|
|
- ``<string>``, ``<string_view>``, and ``<mutex>`` no longer include ``<functional>``
|
|
in any C++ version (it was prevously included in C++20 and earlier).
|
|
|
|
- The headers ``<experimental/algorithm>`` and ``<experimental/functional>`` have been removed, since all the contents
|
|
have been implemented in namespace ``std`` for at least two releases.
|
|
|
|
- The formatter specialization ``template<size_t N> struct formatter<const charT[N], charT>``
|
|
has been removed. Since libc++'s format library was marked experimental there
|
|
is no backwards compatibility option. This specialization has been removed
|
|
from the Standard since it was never used, the proper specialization to use
|
|
instead is ``template<size_t N> struct formatter<charT[N], charT>``.
|
|
|
|
- Libc++ used to provide some C++11 tag type global variables in C++03 as an extension, which are removed in
|
|
this release. Those variables were ``std::allocator_arg``, ``std::defer_lock``, ``std::try_to_lock``,
|
|
``std::adopt_lock``, and ``std::piecewise_construct``. Note that the types associated to those variables are
|
|
still provided in C++03 as an extension (e.g. ``std::piecewise_construct_t``). Providing those variables in
|
|
C++03 mode made it impossible to define them properly -- C++11 mandated that they be ``constexpr`` variables,
|
|
which is impossible in C++03 mode. Furthermore, C++17 mandated that they be ``inline constexpr`` variables,
|
|
which led to ODR violations when mixed with the C++03 definition. Cleaning this up is required for libc++ to
|
|
make progress on support for C++20 modules.
|
|
|
|
Upcoming Deprecations and Removals
|
|
----------------------------------
|
|
|
|
- The ``_LIBCPP_AVAILABILITY_CUSTOM_VERBOSE_ABORT_PROVIDED`` macro will not be honored anymore in LLVM 18.
|
|
Please see the updated documentation about the safe libc++ mode and in particular the ``_LIBCPP_VERBOSE_ABORT``
|
|
macro for details.
|
|
|
|
- The headers ``<experimental/deque>``, ``<experimental/forward_list>``, ``<experimental/list>``,
|
|
``<experimental/map>``, ``<experimental/memory_resource>``, ``<experimental/regex>``, ``<experimental/set>``,
|
|
``<experimental/string>``, ``<experimental/unordered_map>``, ``<experimental/unordered_set>``,
|
|
and ``<experimental/vector>`` will be removed in LLVM 18, as all their contents will have been implemented in
|
|
namespace ``std`` for at least two releases.
|
|
|
|
API Changes
|
|
-----------
|
|
|
|
ABI Affecting Changes
|
|
---------------------
|
|
|
|
- Symbols for ``std::allocator_arg``, ``std::defer_lock``, ``std::try_to_lock``, ``std::adopt_lock``, and
|
|
``std::piecewise_construct`` have been removed from the built library. Under most circumstances, user code
|
|
should not have been relying on those symbols anyway since those are empty classes and the compiler does
|
|
not generate an undefined reference unless the address of the object is taken. However, this is an ABI break
|
|
if the address of one of these objects has been taken in code compiled as C++03, since in those cases the
|
|
objects were marked as defined in the shared library. In other Standard modes, this should never be a problem
|
|
since those objects were defined in the headers as ``constexpr``.
|
|
|
|
Build System Changes
|
|
--------------------
|
|
|
|
- Building libc++ and libc++abi for Apple platforms now requires targeting macOS 10.13 and later.
|
|
This is relevant for vendors building the libc++ shared library and for folks statically linking
|
|
libc++ into an application that has back-deployment requirements on Apple platforms.
|