maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/libcxx/include/__assert

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

60 lines
2.2 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-15 02:41:09 +08: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
#include <__config>
[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
2022-07-26 01:43:47 +08:00
#include <__verbose_abort>
[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-15 02:41:09 +08:00
#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
# pragma GCC system_header
#endif
[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-04 06:37:03 +08:00
// This is for backwards compatibility with code that might have been enabling
// assertions through the Debug mode previously.
[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
2022-04-02 04:38:30 +08:00
// TODO: In LLVM 16, make it an error to define _LIBCPP_DEBUG
#if defined(_LIBCPP_DEBUG)
# ifndef _LIBCPP_ENABLE_ASSERTIONS
# define _LIBCPP_ENABLE_ASSERTIONS 1
# endif
#endif
// Automatically enable assertions when the debug mode is enabled.
#if defined(_LIBCPP_ENABLE_DEBUG_MODE)
[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-04 06:37:03 +08:00
# ifndef _LIBCPP_ENABLE_ASSERTIONS
# define _LIBCPP_ENABLE_ASSERTIONS 1
# endif
#endif
#ifndef _LIBCPP_ENABLE_ASSERTIONS
# define _LIBCPP_ENABLE_ASSERTIONS _LIBCPP_ENABLE_ASSERTIONS_DEFAULT
#endif
#if _LIBCPP_ENABLE_ASSERTIONS != 0 && _LIBCPP_ENABLE_ASSERTIONS != 1
# error "_LIBCPP_ENABLE_ASSERTIONS must be set to 0 or 1"
#endif
#if _LIBCPP_ENABLE_ASSERTIONS
[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
2022-03-24 21:27:03 +08:00
# define _LIBCPP_ASSERT(expression, message) \
(__builtin_expect(static_cast<bool>(expression), 1) ? \
(void)0 : \
[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
2022-07-26 01:43:47 +08:00
::std::__libcpp_verbose_abort("%s:%d: assertion %s failed: %s", __FILE__, __LINE__, #expression, message))
[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
2022-04-06 10:16:39 +08:00
#elif !defined(_LIBCPP_ASSERTIONS_DISABLE_ASSUME) && __has_builtin(__builtin_assume)
# define _LIBCPP_ASSERT(expression, message) \
(_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-15 02:41:09 +08:00
#else
[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
2022-04-06 10:16:39 +08:00
# define _LIBCPP_ASSERT(expression, message) ((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-15 02:41:09 +08:00
#endif
#endif // _LIBCPP___ASSERT