The `lldbassert` macro in LLDB behaves like a regular `assert` when assertions are enabled, and otherwise prints a pretty backtrace and prompts the user to file a bug. By default, this is emitted as a diagnostic event, but vendors can provide their own behavior, for example pre-populating a bug report. Recently, we ran into an issue where an `lldbassert` (in the Swift language plugin) would fire excessively, to the point that it was interfering with the usability of the debugger. Once an `lldbasser` has fired, there's no point in bothering the user over and over again for the same problem. This PR solves the problem by introducing a static `std::once_flag` in the macro. This way, every `lldbasser` will fire at most once per lldb instance. rdar://148520448
Include the LLDB version in the lldbassert error message, and prompt users to include it in the bug report. The majority of users that bother filing a bug report just copy past the stack trace and often forget to include this important detail. By putting it after the backtrace and before the prompt, I'm hoping it'll get copy-pasted in. rdar://146793016
Revert to the state after d7796855b879 and use the underlying buffer directly. I was still under the impression that was unsafe, so I did a drive-by fix, which this commit reverts.
Rename `lldb_assert` to `_lldb_assert` to make it more obvious that you shouldn't be using this function directly. Instead, you should use the `lldbassert` macro which becomes a regular assert in a debug/asserts build.
As specified in the docs, 1) raw_string_ostream is always unbuffered and 2) the underlying buffer may be used directly ( 65b13610a5226b84889b923bae884ba395ad084d for further reference ) * Don't call raw_string_ostream::flush(), which is essentially a no-op. * Avoid unneeded calls to raw_string_ostream::str(), to avoid excess indirection.
When hitting an lldbassert in a non-assert build, we emit a blurb including the assertion, the triggering file and line and a pretty backtrace leading up to the issue. Currently, this is all printed to stderr. That's fine on the command line, but when used as library, for example from Xcode, this information doesn't make it to the user. This patch uses the diagnostic infrastructure to report LLDB asserts as diagnostic events. The patch is slightly more complicated than I would've liked because of layering. lldbassert is part of Utility while the debugger diagnostics are implemented in Core. Differential revision: https://reviews.llvm.org/D152866
Whether assertions are enabled or not is orthogonal to the build type which could lead to surprising behavior for lldbassert. Previously, when doing a debug build with assertions disabled, lldbassert would become a NOOP, rather than printing an error like it does in a release build. By definining lldbassert in terms of NDEBUG, it behaves like a regular assert when assertions are enabled, and like a soft assert. Differential revision: https://reviews.llvm.org/D150639
This distinction doesn't matter for an in-tree build, but when building against an installed llvm, only the former is present. This should fix the LLDB Standalone bot: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone/
Call `os_log_fault` when an lldb assert fails. We piggyback off `LLVM_SUPPORT_XCODE_SIGNPOSTS`, which also depends on `os_log`, to avoid having to introduce another CMake check and corresponding define. This patch also adds a small test using lldb-test that verifies we abort with a "regular" assertion when asserts are enabled. Differential revision: https://reviews.llvm.org/D98987