[libc++] Make _LIBCPP_ASSUME usable when it is appropriate (#91801)

libc++ turned off _LIBCPP_ASSUME because turning every debug assert into
__builtin_assume tripped [1]. However, this means we can

[libc++] Make _LIBCPP_ASSUME usable when it is appropriate (#91801)

libc++ turned off _LIBCPP_ASSUME because turning every debug assert into
__builtin_assume tripped [1]. However, this means we can't use _LIBCPP_ASSUME
when there is a clear optimization intent. See [2] for discussion of a place
where _LIBCPP_ASSUME would be valuable.

This patch fixes this by not undefining the definition of _LIBCPP_ASSUME and
making sure that we don't attempt to `_LIBCPP_ASSSUME` every assertion in
the library.

[1]: https://discourse.llvm.org/t/llvm-assume-blocks-optimization/71609
[2]: https://github.com/llvm/llvm-project/pull/78929#issuecomment-1936582711

show more ...

[libc++] Clean up includes of <__assert> (#80091)

Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
th

[libc++] Clean up includes of <__assert> (#80091)

Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
that mechanism anymore, we don't need to declare __libcpp_verbose_abort
from all public headers, and we can clean up a lot of unnecessary
includes.

This patch also moves the definition of the various assertion categories
to the <__assert> header, since we now rely on regular IWYU for these
assertion macros.

rdar://105510916

show more ...

[libc++][hardening] Rework how the assertion handler can be overridden. (#77883)

Previously there were two ways to override the verbose abort function
which gets called when a hardening assertion i

[libc++][hardening] Rework how the assertion handler can be overridden. (#77883)

Previously there were two ways to override the verbose abort function
which gets called when a hardening assertion is triggered:
- compile-time: define the `_LIBCPP_VERBOSE_ABORT` macro;
- link-time: provide a definition of `__libcpp_verbose_abort` function.

This patch adds a new configure-time approach: the vendor can provide
a path to a custom header file which will get copied into the build by
CMake and included by the library. The header must provide a definition
of the
`_LIBCPP_ASSERTION_HANDLER` macro which is what will get called should
a hardening assertion fail. As of this patch, overriding
`_LIBCPP_VERBOSE_ABORT` will still work, but the previous mechanisms
will be effectively removed in a follow-up patch, making the
configure-time mechanism the sole way of overriding the default handler.

Note that `_LIBCPP_ASSERTION_HANDLER` only gets invoked when a hardening
assertion fails. It does not affect other cases where
`_LIBCPP_VERBOSE_ABORT` is currently used (e.g. when an exception is
thrown in the `-fno-exceptions` mode).

The library provides a default version of the custom header file that
will get used if it's not overridden by the vendor. That allows us to
always test the override mechanism and reduces the difference in
configuration between the pristine version of the library and
a platform-specific version.

show more ...

[libc++][hardening] Deprecate `_LIBCPP_ENABLE_ASSERTIONS`.

`_LIBCPP_ENABLE_ASSERTIONS` was used to enable the "safe" mode in
libc++. Libc++ now provides the hardened mode and the debug mode that
rep

[libc++][hardening] Deprecate `_LIBCPP_ENABLE_ASSERTIONS`.

`_LIBCPP_ENABLE_ASSERTIONS` was used to enable the "safe" mode in
libc++. Libc++ now provides the hardened mode and the debug mode that
replace the safe mode.

For backward compatibility, enabling `_LIBCPP_ENABLE_ASSERTIONS` now
enables the hardened mode. Note that the hardened mode provides
a narrower set of checks than the previous "safe" mode (only
security-critical checks that are performant enough to be used in
production).

Differential Revision: https://reviews.llvm.org/D154997

show more ...

[libc++] Remove the legacy debug mode.

See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026

Reviewed By: #libc, Mordante, ldionne

Differential Revision: https://revi

[libc++] Remove the legacy debug mode.

See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026

Reviewed By: #libc, Mordante, ldionne

Differential Revision: https://reviews.llvm.org/D153672

show more ...

[libc++] Stop using __builtin_assume in _LIBCPP_ASSERT

__builtin_assume can sometimes worsen code generation. For now, the
guideline seems to be to avoid adding assumptions without a clear
optimizat

[libc++] Stop using __builtin_assume in _LIBCPP_ASSERT

__builtin_assume can sometimes worsen code generation. For now, the
guideline seems to be to avoid adding assumptions without a clear
optimization intent. Since _LIBCPP_ASSERT is very general, we can't
have a clear optimization intent at this level, which makes
__builtin_assume the wrong tool for the job -- at least until
__builtin_assume is changed.

See https://discourse.llvm.org/t/llvm-assume-blocks-optimization/71609
for a discussion of this.

Differential Revision: https://reviews.llvm.org/D153968

show more ...

[libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.

Replace most uses of `_LIBCPP_ASSERT` with
`_LIBCPP_ASSERT_UNCATEGORIZED`.

This is done as a prerequisite to introducing hardened

[libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.

Replace most uses of `_LIBCPP_ASSERT` with
`_LIBCPP_ASSERT_UNCATEGORIZED`.

This is done as a prerequisite to introducing hardened mode to libc++.
The idea is to make enabling assertions an opt-in with (somewhat)
fine-grained controls over which categories of assertions are enabled.
The vast majority of assertions are currently uncategorized; the new
macro will allow turning on `_LIBCPP_ASSERT` (the underlying mechanism
for all kinds of assertions) without enabling all the uncategorized
assertions (in the future; this patch preserves the current behavior).

Differential Revision: https://reviews.llvm.org/D153816

show more ...

[libcxx] Add new line after assert message

Abort signal handler may print aswell. Without new line it goes into the
same.

Reviewed By: #libc, philnik, Mordante

Differential Revision: https://revie

[libcxx] Add new line after assert message

Abort signal handler may print aswell. Without new line it goes into the
same.

Reviewed By: #libc, philnik, Mordante

Differential Revision: https://reviews.llvm.org/D142184

show more ...

[libc++] Remove #error about _LIBCPP_DEBUG

This doesn't require a release note since this used to be an error,
so nobody should have been using it anymore.

[libc++] Use __builtin_FILE and __builtin_LINE in _LIBCPP_ASSERT

This avoids theoretical potential ODR violations since __LINE__ and
__FILE__ expand to different things depending on where they are.

[libc++] Use __builtin_FILE and __builtin_LINE in _LIBCPP_ASSERT

This avoids theoretical potential ODR violations since __LINE__ and
__FILE__ expand to different things depending on where they are.

Differential Revision: https://reviews.llvm.org/D143443

show more ...

[libc++][NFC] Reformat __assert with clang-format

[libc++] Introduce a compile-time mechanism to override __libcpp_verbose_abort

This changes the mechanism for verbose termination (again!) to make it
support compile-time customization in addition t

[libc++] Introduce a compile-time mechanism to override __libcpp_verbose_abort

This changes the mechanism for verbose termination (again!) to make it
support compile-time customization in addition to link-time customization,
which is important for users who need fine-grained control over what code
gets generated around sites that call the verbose termination handler.

This concern had been raised to me both privately by prospecting users
and in https://llvm.org/D140944, so I think it is clearly worth fixing.

We still support _LIBCPP_AVAILABILITY_CUSTOM_VERBOSE_ABORT_PROVIDED for
a limited time since the same functionality can be achieved by overriding
the _LIBCPP_VERBOSE_ABORT macro.

Differential Revision: https://reviews.llvm.org/D141326

show more ...

[libc++] Make it an error to define _LIBCPP_DEBUG

We have been transitioning off of that macro since LLVM 15.

Differential Revision: https://reviews.llvm.org/D137975

[libc++] Rename __libcpp_assertion_handler to __libcpp_verbose_abort

With the goal of reusing that handler to do other things besides
handling assertions (such as terminating when an exception is th

[libc++] Rename __libcpp_assertion_handler to __libcpp_verbose_abort

With the goal of reusing that handler to do other things besides
handling assertions (such as terminating when an exception is thrown
under -fno-exceptions), the name `__libcpp_assertion_handler` doesn't
really make sense anymore.

Furthermore, I didn't want to use the name `__libcpp_abort_handler`,
since that would give the impression that the handler is called
whenever `std::abort()` is called, which is not the case at all.

Differential Revision: https://reviews.llvm.org/D130562

show more ...

[libc++] Generalize the customizeable assertion handler

Instead of taking a fixed set of arguments, use variadics so that
we can pass arbitrary arguments to the handler. This is the first
step towar

[libc++] Generalize the customizeable assertion handler

Instead of taking a fixed set of arguments, use variadics so that
we can pass arbitrary arguments to the handler. This is the first
step towards using the handler to handle other non-assertion-related
failures, like std::unreachable and an exception being thrown in
-fno-exceptions mode, which would improve user experience by including
additional information in crashes (right now, we call abort() without
additional information).

Differential Revision: https://reviews.llvm.org/D130507

show more ...

[libc++] Make the Debug mode a configuration-time only option

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 witho

[libc++] Make the Debug mode a configuration-time only option

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

show more ...

[libcxx] Add flag to disable __builtin_assume in _LIBCPP_ASSERT

Introduce _LIBCPP_ASSERTIONS_DISABLE_ASSUME which makes _LIBCPP_ASSERT
not call __builtin_assume when _LIBCPP_ENABLE_ASSERTIONS == 0.

[libcxx] Add flag to disable __builtin_assume in _LIBCPP_ASSERT

Introduce _LIBCPP_ASSERTIONS_DISABLE_ASSUME which makes _LIBCPP_ASSERT
not call __builtin_assume when _LIBCPP_ENABLE_ASSERTIONS == 0.

Calling __builtin_assume was introduced in D122397.

__builtin_assume is generally supposed to improve optimizations, but can
cause regressions when LLVM has trouble handling the calls to
`llvm.assume()` (see comments in D122397).

Reviewed By: philnik

Differential Revision: https://reviews.llvm.org/D123175

show more ...

[libc++] Use __builtin_expect and __builtin_assume in _LIBCPP_ASSERT

Since we expect the condition to be true most of the time, we might
as well tell the compiler. And when assertions are disabled,

[libc++] Use __builtin_expect and __builtin_assume in _LIBCPP_ASSERT

Since we expect the condition to be true most of the time, we might
as well tell the compiler. And when assertions are disabled, we
might as well tell the compiler that it's allowed to assume that
the condition holds.

Differential Revision: https://reviews.llvm.org/D122397

show more ...

[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

[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

show more ...

[libc++] Remove workarounds for re-defining _LIBCPP_ASSERT in the test suite

As a fly-by fix, enable the complexity-changing assertions in __debug_less
only when the full debug mode is enabled, sinc

[libc++] Remove workarounds for re-defining _LIBCPP_ASSERT in the test suite

As a fly-by fix, enable the complexity-changing assertions in __debug_less
only when the full debug mode is enabled, since debugging level 0 is usually
understood to only contain basic assertions that do not change the complexity
of algorithms.

Differential Revision: https://reviews.llvm.org/D121129

show more ...

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional change: it simply moves
_LIBCPP_ASSERT-related stuff to its own file so as to make it clear that
libc++ assertions and the debug mode are different things. Future patches
will make it possible to enable assertions without enabling the debug
mode.

Differential Revision: https://reviews.llvm.org/D119769

show more ...