[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

3 files changed, 14 insertions, 9 deletions

diff --git a/lldb/docs/resources/contributing.rst b/lldb/docs/resources/contributing.rst
index 5f4b24a8013e..26320f635343 100644
--- a/lldb/docs/resources/contributing.rst
+++ b/lldb/docs/resources/contributing.rst
@@ -66,8 +66,8 @@ rules of thumb:
 
 * Soft assertions.  LLDB provides ``lldbassert()`` as a soft
   alternative to cover the middle ground of situations that indicate a
-  recoverable bug in LLDB.  In a Debug configuration ``lldbassert()``
-  behaves like ``assert()``. In a Release configuration it will print a
+  recoverable bug in LLDB.  When asserts are enabled ``lldbassert()``
+  behaves like ``assert()``. When asserts are disabled, it will print a
   warning and encourage the user to file a bug report, similar to
   LLVM's crash handler, and then return execution. Use these sparingly
   and only if error handling is not otherwise feasible.  Specifically,
diff --git a/lldb/include/lldb/Utility/LLDBAssert.h b/lldb/include/lldb/Utility/LLDBAssert.h
index 471a2f7e824f..524f56fd77c8 100644
--- a/lldb/include/lldb/Utility/LLDBAssert.h
+++ b/lldb/include/lldb/Utility/LLDBAssert.h
@@ -9,13 +9,22 @@
 #ifndef LLDB_UTILITY_LLDBASSERT_H
 #define LLDB_UTILITY_LLDBASSERT_H
 
-#ifdef LLDB_CONFIGURATION_DEBUG
+#ifndef NDEBUG
 #define lldbassert(x) assert(x)
 #else
+#if defined(__clang__)
+// __FILE_NAME__ is a Clang-specific extension that functions similar to
+// __FILE__ but only renders the last path component (the filename) instead of
+// an invocation dependent full path to that file.
+#define lldbassert(x)                                                          \
+  lldb_private::lldb_assert(static_cast<bool>(x), #x, __FUNCTION__,            \
+                            __FILE_NAME__, __LINE__)
+#else
 #define lldbassert(x)                                                          \
   lldb_private::lldb_assert(static_cast<bool>(x), #x, __FUNCTION__, __FILE__,  \
                             __LINE__)
 #endif
+#endif
 
 namespace lldb_private {
 void lldb_assert(bool expression, const char *expr_text, const char *func,
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";