[Lldb-commits] [clang] [lldb] [UBSan][BoundsSafety] Implement support for more expressive "trap reasons" (PR #154618)

[Dan Liew via lldb-commits]

================
@@ -1534,6 +1536,103 @@ inline DiagnosticBuilder DiagnosticsEngine::Report(unsigned DiagID) {
   return Report(SourceLocation(), DiagID);
 }
 
+//===----------------------------------------------------------------------===//
+// RuntimeTrapDiagnosticBuilder and helper classes
+//===----------------------------------------------------------------------===//
+
+/// Helper class for \class RuntimeTrapDiagnosticBuilder. This class stores the
+/// "trap reason" built by \class RuntimeTrapDiagnosticBuilder. This consists of
+/// a trap message and trap category.
+///
+/// It is intended that this object be allocated on the stack.
+class TrapReason {
+public:
+  TrapReason() {}
+  /// \return The trap message. Note the lifetime of the underlying storage for
+  /// the returned StringRef lives in this class which means the returned
+  /// StringRef should not be used after this class is destroyed.
+  StringRef getMessage() const { return Message; }
+
+  /// \return the trap category (e.g. "Undefined Behavior Sanitizer")
+  StringRef getCategory() const { return Category; }
+
+  bool isEmpty() const { return Message.size() == 0 && Category.size() == 0; }
----------------
delcypher wrote:

Ah. So there is a reason the logic is written this way. This is because in the `-fbounds-safety` implementation downstream we sometimes emit a category with an empty message. We do this for cases in codegen where (unfortunately) a bunch of the necessary information to explain the trap has been lost and so we emit the trap with a category so its clear what type of trap it is but keep the message empty because there's nothing useful that can be said about the specific reason for trapping.

https://github.com/llvm/llvm-project/pull/154618