aboutsummaryrefslogtreecommitdiff
path: root/lldb/packages/Python/lldbsuite
diff options
context:
space:
mode:
authorAdrian Vogelsgesang <avogelsgesang@salesforce.com>2024-10-10 19:27:27 +0200
committerGitHub <noreply@github.com>2024-10-10 19:27:27 +0200
commit7e16571eb02e7e9da24fee45359e981af783d0d0 (patch)
treec87c7035f787f62bb8f64608f85f790db9e9ef89 /lldb/packages/Python/lldbsuite
parent2f22656db541e4e5c3401e7bbab25277c8438a23 (diff)
downloadllvm-7e16571eb02e7e9da24fee45359e981af783d0d0.zip
llvm-7e16571eb02e7e9da24fee45359e981af783d0d0.tar.gz
llvm-7e16571eb02e7e9da24fee45359e981af783d0d0.tar.bz2
[lldb][libc++] Hide all libc++ implementation details from stacktraces (#108870)
This commit changes the libc++ frame recognizer to hide implementation details of libc++ more aggressively. The applied heuristic is rather straightforward: We consider every function name starting with `__` as an implementation detail. This works pretty neatly for `std::invoke`, `std::function`, `std::sort`, `std::map::emplace` and many others. Also, this should align quite nicely with libc++'s general coding convention of using the `__` for their implementation details, thereby keeping the future maintenance effort low. However, this heuristic by itself does not work in 100% of the cases: E.g., `std::ranges::sort` is not a function, but an object with an overloaded `operator()`, which means that there is no actual call `std::ranges::sort` in the call stack. Instead, there is a `std::ranges::__sort::operator()` call. To make sure that we don't hide this stack frame, we never hide the frame which represents the entry point from user code into libc++ code
Diffstat (limited to 'lldb/packages/Python/lldbsuite')
0 files changed, 0 insertions, 0 deletions