Libc++ hardening went through several iterations, sometimes within a
single release. However, some folks in the wild have picked up these
macros that were either public at some point or that were used
temporarily on `main`, and unfortunately those are now ignored.
This can lead to some users thinking they enable hardening when in
reality they don't, which is a pretty big deal. This patch simply checks
various old hardening-related macros and ensures that they are not set,
which will catch such misuse.
Assertion semantics closely mimic C++26 Contracts evaluation semantics.
This brings our implementation closer in line with C++26 Library Hardening
(one particular benefit is that using the `observe` semantic makes adopting
hardening easier for projects).
Unlike `verbose_abort`, this function merely logs the error but does not
terminate execution. It is intended to make it possible to implement the
`observe` semantic for Hardening.
Assertion semantics closely mimic C++26 Contracts evaluation semantics.
This brings our implementation closer in line with C++26 Library
Hardening (one particular benefit is that using the `observe` semantic
makes adopting hardening easier for projects).
For these annotations to do anything you need `-Wthread-safety`, in
which case users most likely enable them anyways. This avoids that users
have to explictly define a macro just to use the feature they already
had to opt-in to.
This reverts commit c861fe8a71e64f3d2108c58147e7375cd9314521.
Unfortunately, this use of hidden visibility attributes causes
user-defined specializations of standard-library types to also be marked
hidden by default, which is incorrect. See discussion thread on #131156.
...and also reverts the follow-up commits:
Revert "[libc++] Add explicit ABI annotations to functions from the block runtime declared in <__functional/function.h> (#140592)"
This reverts commit 3e4c9dc299c35155934688184319d391b298fff7.
Revert "[libc++] Make ABI annotations explicit for windows-specific code (#140507)"
This reverts commit f73287e623a6c2e4a3485832bc3e10860cd26eb5.
Revert "[libc++][NFC] Replace a few "namespace std" with the correct macro (#140510)"
This reverts commit 1d411f27c769a32cb22ce50b9dc4421e34fd40dd.
This patch introduces `_LIBCPP_{BEGIN,END}_EXPLICIT_ABI_ANNOTATIONS`,
which allow us to have implicit annotations for most functions, and just
where it's not "hide_from_abi everything" we add explicit annotations.
This allows us to drop the `_LIBCPP_HIDE_FROM_ABI` macro from most
functions in libc++.
`__has_feature(modules)` is always true in C++20 and later. Instead of
using that, just disable extension warnings if they're not ignored
through the system header machinery anyways.
Requirements on character-like types are updated unconditionally,
because `basic_string` does requires the default-constructibility. It
might be possible to make `basic_string_view` support classes with
non-public trivial default constructor, but this doesn't seem sensible.
libcxxabi's `ItaniumDemangle.h` is also updated to avoid deprecated
features.
This macro isn't required if we define all the functions inline. In
fact, quite a few of the marked functions have already been inlined.
This patch basically only moves code around and adds
`_LIBCPP_HIDE_FROM_ABI` to the places where it's been missing so far.
This also removes inlining hints, since it dropps `inline` in some
places, but that shouldn't make much of a difference. The functions tend
to be either really small, so should be inlined anyways, or are big
enough that they shouldn't be inlined even with an inlinehint.
This allows us to remove the need for `_LIBCPP_TEMPLATE_VIS` and fixes a
bunch of missing annotations for RTTI when used across dylib boundaries.
`_LIBCPP_TEMPLATE_VIS` itself will be removed in a separate patch, since
it touches a lot of code.
This patch is a no-op for Clang. Only GCC is affected.
We only use `_LIBCPP_DISABLE_EXTENSION_WARNINGS` in a single place while
we use extensions all over the place. The warnings are already disabled,
since libc++'s headers are system headers, so this shouldn't be in any
way observable by users.
This macro is only ever used inside the definiton for the various
visibility macros on windows. There, it's defined in multiple places
with different expansions, which makes it more confusing than helpful
when trying to figure out what macro expands to what.
Using the C++11 attribute syntax makes it more strict where attributes
can be applied, reducing the number of possible positions an attribute
can appear in.
We've started using `_LIBCPP_BEGIN_NAMESPACE_STD` and
`_LIBCPP_END_NAMESPACE_STD` for more than just the namespace for a while
now. For example, we're using it to add visibility annotations to types.
This works very well and avoids a bunch of annotations, but doesn't work
for the few places where we have an unversioned namespace. This adds
`_LIBCPP_BEGIN_UNVERSIONED_NAMESPACE_STD` and
`_LIBCPP_END_UNVERSIONED_NAMESPACE_STD` to make it simpler to add new
annotations consistently across the library as well as making it more
explicit that the unversioned namespace is indeed intended.
This is a continuation of what's been started in #89178.
As a drive-by, this also changes the PSTL macro to say `EXPERIMENTAL`
instead of `INCOMPLETE`.
Some templates in the standard library are illegal to specialize for users
(even if the specialization contains user-defined types). The [[clang::no_specializations]]
attribute allows marking such base templates so that the compiler will
diagnose if users try adding a specialization.
`_LIBCPP_NODEBUG` has been disabled temporarily, since there were a few
problems when adding a bunch of annotations throughout the code base.
They have been resolved now, so we can enable all the annotations again.
Reverts llvm/llvm-project#122393
Identifiers `clang` and `noescape` are not reserved by the C++ standard,
so perhaps we need to use the equivalent reserved forms.
Also changes the occurrences of that attribute to a macro, following the
convention for `[[_Clang::__lifetimebound__]]`.
Addresses
https://github.com/llvm/llvm-project/pull/91651#discussion_r1807852646.
`-fvisibility-global-new-delete` has been added in Clang 18, so there is
no more need to specify the visibility of new/delete via libc++-internal
macros.
Some people used a custom new/delete, which requires them to have
default visibility, but didn't want to leak any symbols otherwise. Since
the new/delete visibility can now be controlled by a compiler flag,
there is no reason to set it with out macro.
https://reviews.llvm.org/D128007 originally tried to remove the option
to override the macro, but was partially reverted because people
actually set this specific macro.
Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`_LIBCPP_HAS_NO_`. This patch changes that, so that they are always
defined and have the prefix `_LIBCPP_HAS_` instead. This changes the
canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means
that using an undefined macro (e.g. due to a missing include) is
diagnosed now. While this is rather unlikely currently, a similar change
in `<__configuration/availability.h>` caught a few bugs. This also
improves readability, since it removes the double-negation of `#ifndef
_LIBCPP_HAS_NO_FEATURE`.
The current patch only touches the macros defined in `<__config>`. If
people are happy with this approach, I'll make a follow-up PR to also
change the macros defined in `<__config_site>`.
This significantly simplifies the code, improves compile times and
improves the object layout of types using `__compressed_pair` in the
unstable ABI. The only downside is that this is extremely ABI sensitive
and pedantically breaks the ABI for empty final types, since the address
of the subobject may change. The ABI of the whole object should not be
affected.
Fixes#91266Fixes#93069
`__has_cpp_attribute(__nodiscard__)` is always true now, so we might as
well replace `_LIBCPP_NODISCARD`. It's one less macro that can result in
bad diagnostics.
We waited before supporting std::jthread fully because we wanted to
investigate other implementation strategies (in particular one involving
std::mutex). Since then, we did some benchmarking and decided that we
wouldn't be moving forward with std::mutex. Hence, there is no real
reason to punt on making std::jthread & friends non-experimental.
