@@ -35,9 +35,25 @@ see the `releases page <https://llvm.org/releases/>`_.
35
35
What's New in Libc++ 18.0.0?
36
36
==============================
37
37
38
- - A new debug mode has been added, replacing the legacy debug mode that was
39
- removed in the LLVM 17 release. See ``libcxx/docs/Hardening.rst `` for more
40
- details.
38
+ The main focus of the libc++ team has been to implement new C++20, C++23,
39
+ and C++26 features.
40
+
41
+ A new debug mode has been added, replacing the legacy debug mode that was
42
+ removed in the LLVM 17 release. See :ref: `hardening-modes ` for more details.
43
+
44
+ Work on the ranges support has progressed. See
45
+ :ref: `ranges-status ` for the current status.
46
+
47
+ Work on the experimental C++23 module support has progressed. The ``std.compat ``
48
+ module is available and the feature is retroactively available in C++20. See
49
+ :ref: `ModulesInLibcxx ` for more information.
50
+
51
+ Work on the experimental C++17 Parallel STL has progressed. See
52
+ :ref: `pstl-status ` for the current status.
53
+
54
+ Work on the experimental C++17 SIMD support has progressed. See
55
+ :ref: `parallelism-status ` for the current status.
56
+
41
57
42
58
Implemented Papers
43
59
------------------
@@ -65,7 +81,7 @@ Implemented Papers
65
81
Improvements and New Features
66
82
-----------------------------
67
83
68
- - ``std::ranges::count `` is now optimized for ``vector<bool>::iterator ``, which
84
+ - ``std::ranges::count `` is now optimized for ``std:: vector<bool>::iterator ``, which
69
85
can lead up to 350x performance improvements.
70
86
71
87
- ``std::for_each `` has been optimized for segmented iterators like ``std::deque::iterator `` in C++23 and
@@ -89,6 +105,11 @@ Improvements and New Features
89
105
- The ``_LIBCPP_ENABLE_CXX20_REMOVED_SHARED_PTR_UNIQUE `` macro has been added to make
90
106
the function ``std::shared_ptr<...>::unique() `` available.
91
107
108
+ - Asan annotations have been added to ``std::basic_string ``.
109
+
110
+ - The libc++ source code has been formatted with ``clang-format ``. This
111
+ `discourse thread <https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all >`_
112
+ contains information how to rebase downstream patches.
92
113
93
114
Deprecations and Removals
94
115
-------------------------
@@ -101,7 +122,7 @@ Deprecations and Removals
101
122
- The non-conforming constructor ``std::future_error(std::error_code) `` has been removed. Please use the
102
123
``std::future_error(std::future_errc) `` constructor provided in C++17 instead.
103
124
104
- - `P1957 <https://wg21.link/P1957> ` has been implemented in Clang and libc++ removed a code path that led to
125
+ - `P1957 <https://wg21.link/P1957 >`_ has been implemented in Clang and libc++ removed a code path that led to
105
126
narrowing conversions in ``std::variant `` behaving in a non-standard way. This may change how some uses of
106
127
``std::variant ``'s constructor behave in user code. The ``_LIBCPP_ENABLE_NARROWING_CONVERSIONS_IN_VARIANT ``
107
128
macro is provided to restore the previous behavior, and it will be supported in the LLVM 18 release only.
@@ -129,12 +150,23 @@ Deprecations and Removals
129
150
that were removed in the C++17 and C++20 standards. Instead of using these
130
151
macros, please use the macros to re-enable individual features.
131
152
153
+ - The macro ``_LIBCPP_INLINE_VISIBILITY `` has been deprecated in LLVM 18 and
154
+ will be removed entirely in LLVM 19. The macro ``_LIBCPP_HIDE_FROM_ABI `` is
155
+ the drop-in replacement.
156
+
157
+ - The macro ``_VSTD `` has been deprecated in LLVM 18 and will be removed
158
+ entirely in LLVM 19. The code ``std `` is the drop-in replacement.
159
+
160
+
132
161
Upcoming Deprecations and Removals
133
162
----------------------------------
134
163
135
164
LLVM 19
136
165
~~~~~~~
137
166
167
+ - The ``LIBCXX_EXECUTOR `` CMake variable has been deprecated. LLVM 19 will
168
+ completely remove support for the ``*_EXECUTOR `` variables.
169
+
138
170
- The ``LIBCXX_ENABLE_ASSERTIONS `` CMake variable that was used to enable the safe mode will be deprecated and setting
139
171
it will trigger an error; use the ``LIBCXX_HARDENING_MODE `` variable with the value ``extensive `` instead. Similarly,
140
172
the ``_LIBCPP_ENABLE_ASSERTIONS `` macro will be deprecated (setting it to ``1 `` still enables the extensive mode the
@@ -159,6 +191,12 @@ LLVM 19
159
191
``_LIBCPP_ENABLE_CXX20_REMOVED_FEATURES `` macros have been deprecated
160
192
in LLVM 18 and will be removed entirely in LLVM 19.
161
193
194
+ - The macro ``_LIBCPP_INLINE_VISIBILITY `` has been deprecated in LLVM 18 and
195
+ will be removed entirely in LLVM 19.
196
+
197
+ - The macro ``_VSTD `` has been deprecated in LLVM 18 and will be removed
198
+ entirely in LLVM 19.
199
+
162
200
LLVM 20
163
201
~~~~~~~
164
202
@@ -175,12 +213,12 @@ ABI Affecting Changes
175
213
- This release of libc++ added missing visibility annotations on some types in the library. Users compiling with
176
214
``-fvisbility=hidden `` may notice that additional type infos from libc++ are being exported from their ABI. This is
177
215
the correct behavior in almost all cases since exporting the RTTI is required for these types to work properly with
178
- dynamic_cast, exceptions and other mechanisms across binaries. However, if you intend to use libc++ purely as an
216
+ `` dynamic_cast `` , exceptions and other mechanisms across binaries. However, if you intend to use libc++ purely as an
179
217
internal implementation detail (i.e. you use libc++ as a static archive and never export libc++ symbols from your ABI)
180
218
and you notice changes to your exported symbols list, then this means that you were not properly preventing libc++
181
219
symbols from being part of your ABI.
182
220
183
- - The name mangling for intantiations of ``std::projected `` has changed in order to implement P2538R1. This technically
221
+ - The name mangling for instantiations of ``std::projected `` has changed in order to implement P2538R1. This technically
184
222
results in an ABI break, however in practice we expect uses of ``std::projected `` in ABI-sensitive places to be
185
223
extremely rare. Any error resulting from this change should result in a link-time error.
186
224
@@ -191,18 +229,26 @@ ABI Affecting Changes
191
229
to throw a different exception when attempting allocations that are too large
192
230
(``std::bad_alloc `` vs ``std::length_error ``).
193
231
194
- - The layout of some views inside ``std::ranges `` that use the ``movable-box `` exposition-only type as an implementation
195
- detail has changed in order to fix a bug which could result in overwriting user data following the `` movable-box ``
196
- <https://github.com/llvm/llvm-project/issues/70506>.
197
- This was caused by incorrect usage of the ``[[no_unique_address]] `` attribute inside the implementation of ``movable-box ``.
198
- This only affects the layout of the following views: ``take_while_view ``, ``filter_view ``, ``single_view ``, ``drop_while_view ``,
199
- ``repeat_view ``, ``transform_view ``, ``chunk_by_view ``. In order to avoid silent breakage, an ABI tag has been added to
200
- these views such that their mangled name will be different starting in this version of libc++.
201
- As a result, attempting to call a function that expects one of these views will fail to link until the code has been rebuilt
202
- against a matching version of libc++. In practice, we believe it is unusual for these views to appear at ABI boundaries so this
203
- should not be a major problem for most users. However it is probably worth auditing ranges-heavy code for ABI boundaries that
232
+ - The layout of some views inside ``std::ranges `` that use the ``movable-box `` exposition-only type as an implementation
233
+ detail has changed in order to fix a ` bug < https://github.com/llvm/llvm-project/issues/70506 >`_ which could result in
234
+ overwriting user data following the `` movable-box ``.
235
+ This was caused by incorrect usage of the ``[[no_unique_address]] `` attribute inside the implementation of ``movable-box ``.
236
+ This affects the layout of the following views: ``take_while_view ``, ``filter_view ``, ``single_view ``, ``drop_while_view ``,
237
+ ``repeat_view ``, ``transform_view ``, ``chunk_by_view ``. In order to avoid silent breakage, an ABI tag has been added to
238
+ these views such that their mangled name will be different starting in this version of libc++.
239
+ As a result, attempting to call a function that expects one of these views will fail to link until the code has been rebuilt
240
+ against a matching version of libc++. In practice, we believe it is unusual for these views to appear at ABI boundaries so this
241
+ should not be a major problem for most users. However it is probably worth auditing ranges-heavy code for ABI boundaries that
204
242
would contain these views, or for types that contain these views as members and which are passed across ABI boundaries.
205
243
244
+ - Some properties of libc++ may cause ODR-violations when mixing multiple libc++
245
+ instances. To avoid these, often benign, ODR-violations the ODR-affecting
246
+ properties are now part of the ABI tag. The ODR-affecting properties are:
247
+
248
+ - library version
249
+ - exceptions vs no-exceptions
250
+ - hardening mode
251
+
206
252
Build System Changes
207
253
--------------------
208
254
0 commit comments