Changes in __assert

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

Tue, 17 Sep 2024 15:22:27 +0000

[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 List of files: /llvm-project/libcxx/include/__assert

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

Thu, 29 Feb 2024 15:12:22 +0000

[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 List of files: /llvm-project/libcxx/include/__assert

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

Thu, 18 Jan 2024 02:56:07 +0000

[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. List of files: /llvm-project/libcxx/include/__assert

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

Fri, 14 Jul 2023 23:58:15 +0000

[libc++][hardening] Deprecate `_LIBCPP_ENABLE_ASSERTIONS`.`_LIBCPP_ENABLE_ASSERTIONS` was used to enable the "safe" mode inlibc++. Libc++ now provides the hardened mode and the debug mode thatreplace the safe mode.For backward compatibility, enabling `_LIBCPP_ENABLE_ASSERTIONS` nowenables the hardened mode. Note that the hardened mode providesa narrower set of checks than the previous "safe" mode (onlysecurity-critical checks that are performant enough to be used inproduction).Differential Revision: https://reviews.llvm.org/D154997 List of files: /llvm-project/libcxx/include/__assert

b5270ba20dc3d84df9d880be11d57667f04c6c28 - [libc++] Remove the legacy debug mode.

Thu, 29 Jun 2023 21:49:45 +0000

[libc++] Remove the legacy debug mode.See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026Reviewed By: #libc, Mordante, ldionneDifferential Revision: https://reviews.llvm.org/D153672 List of files: /llvm-project/libcxx/include/__assert

e7c63c0e90a952f6e6fdd40f9d27b2e8338dd4ac - [libc++] Stop using __builtin_assume in _LIBCPP_ASSERT

Wed, 28 Jun 2023 13:22:34 +0000

[libc++] Stop using __builtin_assume in _LIBCPP_ASSERT__builtin_assume can sometimes worsen code generation. For now, theguideline seems to be to avoid adding assumptions without a clearoptimization intent. Since _LIBCPP_ASSERT is very general, we can'thave 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/71609for a discussion of this.Differential Revision: https://reviews.llvm.org/D153968 List of files: /llvm-project/libcxx/include/__assert

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

Tue, 27 Jun 2023 23:40:39 +0000

[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 newmacro will allow turning on `_LIBCPP_ASSERT` (the underlying mechanismfor all kinds of assertions) without enabling all the uncategorizedassertions (in the future; this patch preserves the current behavior).Differential Revision: https://reviews.llvm.org/D153816 List of files: /llvm-project/libcxx/include/__assert

c4bd5977f429629fda2045eaf80f6ad85982f592 - [libcxx] Add new line after assert message

Fri, 20 Jan 2023 07:32:12 +0000

[libcxx] Add new line after assert messageAbort signal handler may print aswell. Without new line it goes into thesame.Reviewed By: #libc, philnik, MordanteDifferential Revision: https://reviews.llvm.org/D142184 List of files: /llvm-project/libcxx/include/__assert

ff573a42cd1f1d05508f165dc3e645a0ec17edb5 - [libc++] Remove #error about _LIBCPP_DEBUG

Tue, 07 Feb 2023 15:42:30 +0000

[libc++] Remove #error about _LIBCPP_DEBUGThis doesn't require a release note since this used to be an error,so nobody should have been using it anymore. List of files: /llvm-project/libcxx/include/__assert

c5c329b75287b070f1ac005493e0392a5041311a - [libc++] Use __builtin_FILE and __builtin_LINE in _LIBCPP_ASSERT

Tue, 07 Feb 2023 00:11:14 +0000

[libc++] Use __builtin_FILE and __builtin_LINE in _LIBCPP_ASSERTThis 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 List of files: /llvm-project/libcxx/include/__assert

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

Tue, 07 Feb 2023 15:34:29 +0000

[libc++][NFC] Reformat __assert with clang-format List of files: /llvm-project/libcxx/include/__assert

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

Mon, 09 Jan 2023 21:59:59 +0000

[libc++] Introduce a compile-time mechanism to override __libcpp_verbose_abortThis changes the mechanism for verbose termination (again!) to make itsupport compile-time customization in addition to link-time customization,which is important for users who need fine-grained control over what codegets generated around sites that call the verbose termination handler.This concern had been raised to me both privately by prospecting usersand in https://llvm.org/D140944, so I think it is clearly worth fixing.We still support _LIBCPP_AVAILABILITY_CUSTOM_VERBOSE_ABORT_PROVIDED fora limited time since the same functionality can be achieved by overridingthe _LIBCPP_VERBOSE_ABORT macro.Differential Revision: https://reviews.llvm.org/D141326 List of files: /llvm-project/libcxx/include/__assert

13ea1343231fa4ae12fe9fba4c789728465783d7 - [libc++] Make it an error to define _LIBCPP_DEBUG

Mon, 14 Nov 2022 19:56:35 +0000

[libc++] Make it an error to define _LIBCPP_DEBUGWe have been transitioning off of that macro since LLVM 15.Differential Revision: https://reviews.llvm.org/D137975 List of files: /llvm-project/libcxx/include/__assert

507125af3d0b953cb56bce2e5b8000249fe1ef53 - [libc++] Rename __libcpp_assertion_handler to __libcpp_verbose_abort

Mon, 25 Jul 2022 17:43:47 +0000

[libc++] Rename __libcpp_assertion_handler to __libcpp_verbose_abortWith the goal of reusing that handler to do other things besideshandling assertions (such as terminating when an exception is thrownunder -fno-exceptions), the name `__libcpp_assertion_handler` doesn'treally 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 calledwhenever `std::abort()` is called, which is not the case at all.Differential Revision: https://reviews.llvm.org/D130562 List of files: /llvm-project/libcxx/include/__assert

7de5aca84c541edd9f11b9316cb61c5f350ee724 - [libc++] Generalize the customizeable assertion handler

Mon, 25 Jul 2022 17:19:51 +0000

[libc++] Generalize the customizeable assertion handlerInstead of taking a fixed set of arguments, use variadics so thatwe can pass arbitrary arguments to the handler. This is the firststep towards using the handler to handle other non-assertion-relatedfailures, like std::unreachable and an exception being thrown in-fno-exceptions mode, which would improve user experience by includingadditional information in crashes (right now, we call abort() withoutadditional information).Differential Revision: https://reviews.llvm.org/D130507 List of files: /llvm-project/libcxx/include/__assert

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

Fri, 01 Apr 2022 20:38:30 +0000

[libc++] Make the Debug mode a configuration-time only optionThe debug mode has been broken pretty much ever since it was shippedbecause it was possible to enable the debug mode in user code withoutactually enabling it in the dylib, leading to ODR violations thatcaused various kinds of failures.This commit makes the debug mode a knob that is configured whenbuilding the library and which can't be changed afterwards. This isless flexible for users, however it will actually work as intendedand it will allow us, in the future, to add various kinds of checksthat do not assume the same ABI as the normal library. Furthermore,this will make the debug mode more robust, which means that vendorsmight be more tempted to support it properly, which hasn't been thecase with the current debug mode.This patch shouldn't break any user code, except folks who are buildingagainst a library that doesn't have the debug mode enabled and who tryto enable the debug mode in their code. Such users will get a compile-timeerror explaining that this configuration isn't supported anymore.In the future, we should further increase the granularity of the debugmode checks so that we can cherry-pick which checks to enable, like wedo for unspecified behavior randomization.Differential Revision: https://reviews.llvm.org/D122941 List of files: /llvm-project/libcxx/include/__assert

0a77e633226b5598e426603c03e54d62ed275670 - [libcxx] Add flag to disable __builtin_assume in _LIBCPP_ASSERT

Wed, 06 Apr 2022 02:16:39 +0000

[libcxx] Add flag to disable __builtin_assume in _LIBCPP_ASSERTIntroduce _LIBCPP_ASSERTIONS_DISABLE_ASSUME which makes _LIBCPP_ASSERTnot call __builtin_assume when _LIBCPP_ENABLE_ASSERTIONS == 0.Calling __builtin_assume was introduced in D122397.__builtin_assume is generally supposed to improve optimizations, but cancause regressions when LLVM has trouble handling the calls to`llvm.assume()` (see comments in D122397).Reviewed By: philnikDifferential Revision: https://reviews.llvm.org/D123175 List of files: /llvm-project/libcxx/include/__assert

f0799465b2cc25738d7164774926a8ba3a63b98d - [libc++] Use __builtin_expect and __builtin_assume in _LIBCPP_ASSERT

Thu, 24 Mar 2022 13:27:03 +0000

[libc++] Use __builtin_expect and __builtin_assume in _LIBCPP_ASSERTSince we expect the condition to be true most of the time, we mightas well tell the compiler. And when assertions are disabled, wemight as well tell the compiler that it's allowed to assume thatthe condition holds.Differential Revision: https://reviews.llvm.org/D122397 List of files: /llvm-project/libcxx/include/__assert

b0fd9497af6d2efd305e9eecfa0c1e265f1b2192 - [libc++] Add a lightweight overridable assertion handler

Thu, 03 Mar 2022 22:37:03 +0000

[libc++] Add a lightweight overridable assertion handlerThis patch adds a lightweight assertion handler mechanism that can beoverriden at link-time in a fashion similar to `operator new`.This is a third take on https://llvm.org/D121123 (which allowed customizingthe 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 whendeploying to older platforms that don't have a default handler inthe dylib.As-is, this patch provides a pretty good amount of backwards compatibilitywith 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 withassertions enabled but deploying to an older platform where the assertionhandler didn't exist yet will fail to compile. However users can easilyfix the problem by providing a custom assertion handler and definingthe _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro tolet the library know about the custom handler. In a way, this isactually a feature because it avoids a load-time error that one wouldotherwise get when trying to run the code on the older target.Differential Revision: https://reviews.llvm.org/D121478 List of files: /llvm-project/libcxx/include/__assert

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

Mon, 07 Mar 2022 16:31:45 +0000

[libc++] Remove workarounds for re-defining _LIBCPP_ASSERT in the test suiteAs a fly-by fix, enable the complexity-changing assertions in __debug_lessonly when the full debug mode is enabled, since debugging level 0 is usuallyunderstood to only contain basic assertions that do not change the complexityof algorithms.Differential Revision: https://reviews.llvm.org/D121129 List of files: /llvm-project/libcxx/include/__assert