[lldb][test] Fix `LibCxxInternalsRecognizerTestCase` on clang <= 17 (#114122)

We had to disable the tests for libc++ <= 15 because the `std::ranges`
functions were not available, yet.

Also, on l

[lldb][test] Fix `LibCxxInternalsRecognizerTestCase` on clang <= 17 (#114122)

We had to disable the tests for libc++ <= 15 because the `std::ranges`
functions were not available, yet.

Also, on libc++17 there was still an additional `__fn` struct withing
`ranges::__sort`. The test expectation was updated to use a regular
expression, so we can match both the old and the new name.

See
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-matrix/912/execution/node/107/log/

show more ...

[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 appl

[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

show more ...