diff options
author | Adrian Vogelsgesang <avogelsgesang@salesforce.com> | 2024-10-10 19:27:27 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-10-10 19:27:27 +0200 |
commit | 7e16571eb02e7e9da24fee45359e981af783d0d0 (patch) | |
tree | c87c7035f787f62bb8f64608f85f790db9e9ef89 /lldb/packages/Python/lldbsuite | |
parent | 2f22656db541e4e5c3401e7bbab25277c8438a23 (diff) | |
download | llvm-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