This patch refactors the trap reason demangling logic in
`lldb_private::VerboseTrapFrameRecognizer::RecognizeFrame` into a new
public function `clang::CodeGen::DemangleTrapReasonInDebugInfo`.
There are two reasons for doing this:
1. In a future patch the logic for demangling needs to be used somewhere
else in LLDB and thus the logic needs refactoring to avoid duplicating
code.
2. The logic for demangling shouldn't really be in LLDB anyway because
it's a Clang implementation detail and thus the logic really belongs
inside Clang, not LLDB.
Unit tests have been added for the new function that demonstrate how to
use the new API.
The function names recognized by VerboseTrapFrameRecognizer are
identical to before. However, this patch isn't NFC because:
* The `lldbTarget` library now links against `clangCodeGen` which it
didn't previously.
* The LLDB logging output is a little different now. The previous code
tried to log failures for an invalid regex pattern and for the
`Regex::match` API not returning the correct number of matches. These
failure conditions are unreachable via unit testing so they have been
made assertions failures inside the `DemangleTrapReasonInDebugInfo`
implementation instead of trying to log them in LLDB.
rdar://163230807
https://github.com/llvm/llvm-project/pull/165996 is adding a Clang
dependency to Target because we're moving some of the functionality of
the VerboseTrapFrameRecognizer into libClang. To avoid adding this
dependency this patch moves VerboseTrapFrameRecognizer into the
CPPLanguageRuntime. Most of the frame recognizers already live in the
various runtime plugins.
An alternative discussed was to create a common `CLanguageRuntime` whose
currently sole responsibility was to register the
`VerboseTrapFrameRecognizer` and `AssertStackFrameRecognizer`. The main
issue I ran into here was frame recognizers aren't uniqued in the
target. Currently this only manifests when re-running a target, which
re-triggers all the recognizer registration (added a test with a FIXME
for this). If we had a common `CLanguageRuntime` that
`CPPLanguageRuntime` and `ObjCLanguageRuntime` inherited from, I didn't
find a great way to avoid registering the recognizer multiple times. We
can't just call_once on it because we do want the recognisers to be
re-registered for new targets in the same debugger session. If the
recognisers were stored in something like a UniqueVector in the Target,
then we wouldn't have that issue. But currently that's not the case, and
it would take a bit of refactoring to de-dupe the recognisers.
There may very well be solutions I haven't considered, but all the
things I've tried so far I wasn't very happy with. So in the end I just
moved this to the C++ runtime for now in order to unblock
https://github.com/llvm/llvm-project/pull/165996.
The C++ language runtime is always available (even for C targets) if the
C++ language plugin is available. Which it should also be unless someone
is using an LLDB with the C++ plugin compiled out. But at that point
numerous things wouldn't work when even debugging just C.
