mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-26 17:56:05 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/libcxx/include/__assert

119 lines
7.0 KiB
Plaintext
Raw Normal View History

[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
2022-02-14 13:41:09 -05:00
// -*- C++ -*-
//===----------------------------------------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#ifndef _LIBCPP___ASSERT
#define _LIBCPP___ASSERT
[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.
2024-01-17 18:56:07 -08:00
#include <__assertion_handler> // Note: this include is generated by CMake and is potentially vendor-provided.
[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
2022-02-14 13:41:09 -05:00
#include <__config>
#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
# pragma GCC system_header
#endif
[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
2023-07-14 16:58:15 -07:00
#define _LIBCPP_ASSERT(expression, message) \
(__builtin_expect(static_cast<bool>(expression), 1) \
? (void)0 \
[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.
2024-01-17 18:56:07 -08:00
: _LIBCPP_ASSERTION_HANDLER(__FILE__ ":" _LIBCPP_TOSTRING(__LINE__) ": assertion " _LIBCPP_TOSTRING( \
expression) " failed: " message "\n"))
[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
2022-03-03 17:37:03 -05:00
[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
2024-09-17 11:22:27 -04:00
// WARNING: __builtin_assume can currently inhibit optimizations. Only add assumptions with a clear
// optimization intent. See https://discourse.llvm.org/t/llvm-assume-blocks-optimization/71609 for a
// discussion.
#if __has_builtin(__builtin_assume)
[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
2023-07-14 16:58:15 -07:00
# define _LIBCPP_ASSUME(expression) \
[libc++][NFC] Reformat __assert with clang-format
2023-02-07 07:34:29 -08:00
(_LIBCPP_DIAGNOSTIC_PUSH _LIBCPP_CLANG_DIAGNOSTIC_IGNORED("-Wassume") \
__builtin_assume(static_cast<bool>(expression)) _LIBCPP_DIAGNOSTIC_POP)
[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
2022-02-14 13:41:09 -05:00
#else
[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
2023-07-14 16:58:15 -07:00
# define _LIBCPP_ASSUME(expression) ((void)0)
[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
2022-02-14 13:41:09 -05:00
#endif
[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
2024-02-29 10:12:22 -05:00
// clang-format off
// Fast hardening mode checks.
#if _LIBCPP_HARDENING_MODE == _LIBCPP_HARDENING_MODE_FAST
// Enabled checks.
# define _LIBCPP_ASSERT_VALID_INPUT_RANGE(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(expression, message) _LIBCPP_ASSERT(expression, message)
// Disabled checks.
// On most modern platforms, dereferencing a null pointer does not lead to an actual memory access.
[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
2024-09-17 11:22:27 -04:00
# define _LIBCPP_ASSERT_NON_NULL(expression, message) ((void)0)
[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
2024-02-29 10:12:22 -05:00
// Overlapping ranges will make algorithms produce incorrect results but don't directly lead to a security
// vulnerability.
[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
2024-09-17 11:22:27 -04:00
# define _LIBCPP_ASSERT_NON_OVERLAPPING_RANGES(expression, message) ((void)0)
# define _LIBCPP_ASSERT_VALID_DEALLOCATION(expression, message) ((void)0)
# define _LIBCPP_ASSERT_VALID_EXTERNAL_API_CALL(expression, message) ((void)0)
# define _LIBCPP_ASSERT_COMPATIBLE_ALLOCATOR(expression, message) ((void)0)
# define _LIBCPP_ASSERT_ARGUMENT_WITHIN_DOMAIN(expression, message) ((void)0)
# define _LIBCPP_ASSERT_PEDANTIC(expression, message) ((void)0)
# define _LIBCPP_ASSERT_SEMANTIC_REQUIREMENT(expression, message) ((void)0)
# define _LIBCPP_ASSERT_INTERNAL(expression, message) ((void)0)
# define _LIBCPP_ASSERT_UNCATEGORIZED(expression, message) ((void)0)
[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
2024-02-29 10:12:22 -05:00
// Extensive hardening mode checks.
#elif _LIBCPP_HARDENING_MODE == _LIBCPP_HARDENING_MODE_EXTENSIVE
// Enabled checks.
# define _LIBCPP_ASSERT_VALID_INPUT_RANGE(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_NON_NULL(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_NON_OVERLAPPING_RANGES(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_VALID_DEALLOCATION(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_VALID_EXTERNAL_API_CALL(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_COMPATIBLE_ALLOCATOR(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_ARGUMENT_WITHIN_DOMAIN(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_PEDANTIC(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_UNCATEGORIZED(expression, message) _LIBCPP_ASSERT(expression, message)
// Disabled checks.
[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
2024-09-17 11:22:27 -04:00
# define _LIBCPP_ASSERT_SEMANTIC_REQUIREMENT(expression, message) ((void)0)
# define _LIBCPP_ASSERT_INTERNAL(expression, message) ((void)0)
[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
2024-02-29 10:12:22 -05:00
// Debug hardening mode checks.
#elif _LIBCPP_HARDENING_MODE == _LIBCPP_HARDENING_MODE_DEBUG
// All checks enabled.
# define _LIBCPP_ASSERT_VALID_INPUT_RANGE(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_NON_NULL(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_NON_OVERLAPPING_RANGES(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_VALID_DEALLOCATION(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_VALID_EXTERNAL_API_CALL(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_COMPATIBLE_ALLOCATOR(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_ARGUMENT_WITHIN_DOMAIN(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_PEDANTIC(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_SEMANTIC_REQUIREMENT(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_INTERNAL(expression, message) _LIBCPP_ASSERT(expression, message)
# define _LIBCPP_ASSERT_UNCATEGORIZED(expression, message) _LIBCPP_ASSERT(expression, message)
// Disable all checks if hardening is not enabled.
#else
// All checks disabled.
[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
2024-09-17 11:22:27 -04:00
# define _LIBCPP_ASSERT_VALID_INPUT_RANGE(expression, message) ((void)0)
# define _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(expression, message) ((void)0)
# define _LIBCPP_ASSERT_NON_NULL(expression, message) ((void)0)
# define _LIBCPP_ASSERT_NON_OVERLAPPING_RANGES(expression, message) ((void)0)
# define _LIBCPP_ASSERT_VALID_DEALLOCATION(expression, message) ((void)0)
# define _LIBCPP_ASSERT_VALID_EXTERNAL_API_CALL(expression, message) ((void)0)
# define _LIBCPP_ASSERT_COMPATIBLE_ALLOCATOR(expression, message) ((void)0)
# define _LIBCPP_ASSERT_ARGUMENT_WITHIN_DOMAIN(expression, message) ((void)0)
# define _LIBCPP_ASSERT_PEDANTIC(expression, message) ((void)0)
# define _LIBCPP_ASSERT_SEMANTIC_REQUIREMENT(expression, message) ((void)0)
# define _LIBCPP_ASSERT_INTERNAL(expression, message) ((void)0)
# define _LIBCPP_ASSERT_UNCATEGORIZED(expression, message) ((void)0)
[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
2024-02-29 10:12:22 -05:00
#endif // _LIBCPP_HARDENING_MODE == _LIBCPP_HARDENING_MODE_FAST
// clang-format on
[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
2022-02-14 13:41:09 -05:00
#endif // _LIBCPP___ASSERT
Reference in New Issue Copy Permalink