- Adding support to step into the callable wrapped by libc++ std::function
- Adding test to validate that functionality
jingham davide aprantl EricWF
- rGaa30268539a9: Adding support to step into the callable wrapped by libc++ std::function
rLLDB344371: Adding support to step into the callable wrapped by libc++ std::function
rL344371: Adding support to step into the callable wrapped by libc++ std::function
Some basic comments. Haven't looked at the implementation very closely, I'll do that probably tomorrow. Thanks for working on this!
Please add a doxygen comment to this function. (I understand the surrounding ones are not commented, but we should start somewhere)/
This comment seems a little outdated.
I'm not sure you need these.
Is this affected by the debug info variant used? (i.e. dSYM/gmodules/DWARF/dwo).
All these lines check hardcoded make me a little nervous, as they're really fragile. Can you make them parametric at least?
You don't need a license for the test case, I think.
Can you add a comment here?
Just a couple of trivial requests, mostly about comments...
I don't think this test will be sensitive to those differences, so this probably can be a NO_DEBUG_INFO test.
Most of this setup (excepting the line_number calls) can be done in one line using lldbutils.run_to_source_breakpoint.
Can you also check the source file? The way libcxx does inlining nowadays, all these std::function calls introduce lots of inlining so the chance that you got to the right line but in an inlined function is not zero...
I'm not sure this comment is helpful. You want to do the trampoline detection regardless of the value of the regexp. And we really aren't violating that contract, since we don't intent to STOP on step into std::function...
You need to explain what this step in is about. Otherwise this is pretty mysterious.
Couple more lines you can delete from the test case, and I think you should make this a debug-variant insensitive test. Do that and this is good.
You don't need these two lines anymore. You never use the exe variable, and the target you make with this "file" command is never used (you correctly use the one returned by run_to_source_breakpoint.)
Also, this doesn't seem like a debug variant sensitive test, so you really should make this a NO_DEBUG_INFO test. We're trying to do that wherever it makes sense just to keep down the number of tests we run.