================
@@ -378,3 +379,31 @@ clang::CreateLLVMCodeGen(DiagnosticsEngine &Diags,
llvm::StringRef ModuleName,
HeaderSearchOpts, PreprocessorOpts, CGO, C,
CoverageInfo);
}
+
+namespace clang {
+namespace CodeGen {
+std::optional<std::pair<StringRef, StringRef>>
+DemangleTrapReasonInDebugInfo(StringRef FuncName) {
+ static auto TrapRegex =
+ llvm::Regex(llvm::formatv("^{0}\\$(.*)\\$(.*)$", ClangTrapPrefix).str());
+ llvm::SmallVector<llvm::StringRef, 3> Matches;
+ std::string *ErrorPtr = nullptr;
+#ifndef NDEBUG
+ std::string Error;
+ ErrorPtr = &Error;
+#endif
+ if (!TrapRegex.match(FuncName, &Matches, ErrorPtr)) {
+ assert(ErrorPtr && ErrorPtr->empty() && "Invalid regex pattern");
+ return {};
+ }
+
+ if (Matches.size() != 3) {
+ assert(0 && "Expected 3 matches from Regex::match");
----------------
delcypher wrote:
I don't know how it would be possible to assert here unless the `llvm::Regex`
behavior changed. If the pattern matched there should be `3` matches exactly.
If the behavior of `llvm::Regex` did change this seems like something we should
catch with an assert rather than silently ignoring. Even if the mangling scheme
used in the debug info did change in a newer LLDB I think this code in an older
LLDB would:
* Not match the regex pattern at all and so we fail to extract the trap reason
without asserting.
* Does match the regex but the category and message strings don't contain the
correct contents. While not ideal in this case we still wouldn't assert. If we
did change the mangling scheme we probably would try to avoid doing it this way
because the change to the mangling scheme would not be backwards compatible.
https://github.com/llvm/llvm-project/pull/165996
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
