[lldb] Define lldbassert based on NDEBUG instead of LLDB_CONFIGURATION_DEBUG

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

1 files changed, 2 insertions, 6 deletions

diff --git a/lldb/source/Utility/LLDBAssert.cpp b/lldb/source/Utility/LLDBAssert.cpp
index a8d8ef65a945..17689582cdc5 100644
--- a/lldb/source/Utility/LLDBAssert.cpp
+++ b/lldb/source/Utility/LLDBAssert.cpp
@@ -25,9 +25,6 @@ void lldb_private::lldb_assert(bool expression, const char *expr_text,
   if (LLVM_LIKELY(expression))
     return;
 
-  // If asserts are enabled abort here.
-  assert(false && "lldb_assert failed");
-
 #if LLVM_SUPPORT_XCODE_SIGNPOSTS
   if (__builtin_available(macos 10.12, iOS 10, tvOS 10, watchOS 3, *)) {
     os_log_fault(OS_LOG_DEFAULT,
@@ -36,9 +33,8 @@ void lldb_private::lldb_assert(bool expression, const char *expr_text,
   }
 #endif
 
-  // In a release configuration it will print a warning and encourage the user
-  // to file a bug report, similar to LLVM’s crash handler, and then return
-  // execution.
+  // Print a warning and encourage the user to file a bug report, similar to
+  // LLVM’s crash handler, and then return execution.
   errs() << format("Assertion failed: (%s), function %s, file %s, line %u\n",
                    expr_text, func, file, line);
   errs() << "backtrace leading to the failure:\n";