Instead of marking private symbols with internal_linkage (which leads to
one copy per translation unit -- rather wasteful), use an ABI tag that
gets rev'd with each libc++ version. That way, we know that we can't have
name collisions between implementation-detail functions across libc++
versions, so we'll never violate the ODR. However, within a single program,
each symbol still has a proper name with external linkage, which means
that the linker is free to deduplicate symbols even across TUs.
This actually means that we can guarantee that versions of libc++ can
be mixed within the same program without ever having to take a code size
hit, and without having to manually opt-in -- it should just work out of
the box.
Differential Revision: https://reviews.llvm.org/D127444
- P1252 ("Ranges Design Cleanup") -- deprecate
`move_iterator::operator->` starting from C++20; add range comparisons
to the `<functional>` synopsis. This restores
`move_iterator::operator->` that was incorrectly deleted in D117656;
it's still defined in the latest draft, see
http://eel.is/c++draft/depr.move.iter.elem. Note that changes to
`*_result` types from 6.1 in the paper are no longer relevant now that
these types are aliases;
- P2106 ("Alternative wording for GB315 and GB316") -- add a few
`*_result` types to the synopsis in `<algorithm>` (some algorithms are
not implemented yet and thus some of the proposal still cannot be
marked as done);
Also mark already done issues as done (or as nothing to do):
- P2091 ("Fixing Issues With Range Access CPOs") was already implemented
(this patch adds tests for some ill-formed cases);
- LWG 3247 ("`ranges::iter_move` should perform ADL-only lookup of
`iter_move`") was already implemented;
- LWG 3300 ("Non-array ssize overload is underconstrained") doesn't
affect the implementation;
- LWG 3335 ("Resolve C++20 NB comments US 273 and GB 274") was already
implemented;
- LWG 3355 ("The memory algorithms should support move-only input
iterators introduced by P1207") was already implemented (except for
testing).
Differential Revision: https://reviews.llvm.org/D126053
This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3158c604,
and 489637e66dd3. This should cover almost all the includes that had
been removed since LLVM 14 and that would contribute to breaking user
code when releasing LLVM 15.
It is possible to disable the inclusion of these headers by defining
_LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors will
enable that macro and start fixing downstream issues immediately. We
can then remove the macro (and the transitive includes) by default in
a future release. That way, we will break users only once by removing
transitive includes in bulk instead of doing it bit by bit a every
release, which is more disruptive for users.
Note 1: The set of headers to re-add was found by re-generating the
transitive include test on a checkout of release/14.x, which
provided the list of all transitive includes we used to provide.
Note 2: Several includes of <vector>, <optional>, <array> and <unordered_map>
have been added in this commit. These transitive inclusions were
added when we implemented boyer_moore_searcher in <functional>.
Note 3: This is a best effort patch to try and resolve downstream breakage
caused since branching LLVM 14. I wasn't able to perfectly mirror
transitive includes in LLVM 14 for a few headers, so I added a
release note explaining it. To summarize, adding boyer_moore_searcher
created a bunch of circular dependencies, so we have to break
backwards compatibility in a few cases.
Differential Revision: https://reviews.llvm.org/D128661
`__GCC_CONSTRUCTIVE_SIZE` and `__GCC_DESTRUCTIVE_SIZE` are available since GCC 12. I'm assuming clang will also implement these for compatability with libstdc++.
Reviewed By: ldionne, #libc
Spies: h-vetinari, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D122276
`std::function` has been deprecated for a few releases now. Remove it with an option to opt-back-in with a note that this option will be removed in LLVM 16.
Reviewed By: ldionne, #libc
Spies: #libc_vendors, EricWF, jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D127908
This mostly copys the `<experimental/functional>` stuff and updates the code to current libc++ style.
Reviewed By: ldionne, #libc
Spies: nlopes, adamdebreceni, arichardson, libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D121074
When compiled with `-D_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS`
uses of `allocator<void>::pointer` resulted in compiler errors after D104323.
If we instantiate the primary template, `allocator<void>::reference` produces
an error 'cannot form references to void'.
To workaround this, allow to bring back the `allocator<void>` specialization by defining the new `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION` macro.
To make sure the code that uses `allocator<void>` and the removed members does not break,
both `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS` and `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS` have to be defined.
Reviewed By: ldionne, #libc, philnik
Differential Revision: https://reviews.llvm.org/D126210
This removes all "TODO: remove these headers" comments from our headers.
Note there seem to be more headers that can be removed, that will be
done in separate commits.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D127592
The flexibility around extern template instantiation declarations in
libc++ result in a very complicated model, especially when support for
slightly different configurations (like the debug mode or assertions
in the dylib) are taken into account. That results in unexpected bugs
like http://llvm.org/PR50534 (and there have been multiple similar
bugs in the past, notably around the debug mode).
This patch gets rid of the _LIBCPP_DISABLE_EXTERN_TEMPLATE knob, which
I don't think is fundamental. Indeed, the motivation for that knob was to
avoid taking a dependency on the library, however that can be done better
by linking against the static library instead. And in fact, some parts of
the headers will always depend on things defined in the library, which
defeats the original goal of _LIBCPP_DISABLE_EXTERN_TEMPLATE.
Differential Revision: https://reviews.llvm.org/D103960
When some headers are not available because we removed features like
localization or threads, the compiler should not try to include these
headers when building modules. To avoid that from happening, add a
requires-declaration that is never satisfied when the configuration
in use doesn't support a header.
rdar://93777687
Differential Revision: https://reviews.llvm.org/D127127
The debug mode has been broken pretty much ever since it was shipped
because it was possible to enable the debug mode in user code without
actually enabling it in the dylib, leading to ODR violations that
caused various kinds of failures.
This commit makes the debug mode a knob that is configured when
building the library and which can't be changed afterwards. This is
less flexible for users, however it will actually work as intended
and it will allow us, in the future, to add various kinds of checks
that do not assume the same ABI as the normal library. Furthermore,
this will make the debug mode more robust, which means that vendors
might be more tempted to support it properly, which hasn't been the
case with the current debug mode.
This patch shouldn't break any user code, except folks who are building
against a library that doesn't have the debug mode enabled and who try
to enable the debug mode in their code. Such users will get a compile-time
error explaining that this configuration isn't supported anymore.
In the future, we should further increase the granularity of the debug
mode checks so that we can cherry-pick which checks to enable, like we
do for unspecified behavior randomization.
Differential Revision: https://reviews.llvm.org/D122941
After moving the std::to_chars base 10 implementation from the dylib to
the header the integral overloads of std::to_chars are available on all
platforms.
Remove the _LIBCPP_AVAILABILITY_TO_CHARS availability macro and update
the tests.
Depends on D125704
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D125745
Currently, unary expressions involving valarray will create a temporary.
This leads to dangling references in expressions like `-a * b`, because
`-a` is a temporary and the resulting expression will refer to it. This
patch fixes the problem by creating a lazy expression to perform the unary
operation instead of eagerly creating a temporary valarray. This is
permitted by the Standard, which does not specify the exact type of
most expressions involving valarrays.
This is technically an ABI break, however I believe the actual potential
for breakage is very low.
rdar://90152242
Differential Revision: https://reviews.llvm.org/D125019
P0798R8 "Monadic operations for std::optional" has been implemented, so
this LWG issue can be adopted.
During review it was discovered another paper bumped the macro. The
part affecting optional of this paper is done, the variant isn't. The
status page is updated to reflect the current state.
Implements
- LWG 3621 Remove feature-test macro __cpp_lib_monadic_optional
Updates status of
- P2231R1 Missing constexpr in std::optional and std::variant
Reviewed By: #libc, philnik, ldionne
Differential Revision: https://reviews.llvm.org/D125813
Add a warning and tweak the release note to explain that the deprecation
targets libc++, libc++abi and libuwnind as well.
Also, as a fly-by, ensure that our CI runs the legacy testing configuration
for libc++, libc++abi and libunwind. This doesn't matter too much since
it's deprecated, but we might as well test it properly.
Differential Revision: https://reviews.llvm.org/D126478
