You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a little usability issue that's always bugged me, but I never bothered to log an issue. It's like this:
foreach (x; collection) // <- place breakpoint here, press F10 (step-over)
{
x.doSomething();
}
nextLine(); // <- cursor moves to here, completely skipping over the loop
In cases where collection has an opApply function to implement the foreach behaviour, if the cursor is at the foreach statement, and you press F10, instead of stepping into the first line of the loop inner as usual, since the opApply is essentially just a function call, the debugger steps-over the opApply and goes straight to nextLine().
This gives the false impression that the collection is empty; but actually, the reality is that because opApply was a function call, it just stepped over the entire loop. Since opApply is rare, it's easy to miss/forget this detail, and so I find myself constantly making the improper assumption that the collection was empty, which occasionally leads down a rabbit hole chasing other explanations for a problem...
I have no idea how to fix this; it seems like a hard problem... but I wonder if any creative solutions are possible?
Maybe a breakpoint could silently be placed at the entry to the loop-body lambda when the user presses step-over; but it's hard to imagine how to detect the conditions to enable a hack like that.
I guess there could be a solution that involves aggressive/forceful inlining of the opApply and the lambda?
The text was updated successfully, but these errors were encountered:
Indeed not an easy problem. You can use "Step into specific" to get immediately to the loop body lambda (if you know which of the mangled symbols is the right one), maybe that can be automated somehow. But it doesn't get simpler when returning from the lambda: in normal cases with "Step over", you will probably not want to step through the opApply code but the next iteration inside the lambda or continue after the loop.
Inlining might help in some cases, but might also make it more difficult to detect opApply code that should be skipped when stepping over.
Mmmm, it seems like a really hard problem. I wonder if any other languages have a similar situation that pops up often, and have any novel solutions for their cases...
There's a little usability issue that's always bugged me, but I never bothered to log an issue. It's like this:
In cases where
collection
has anopApply
function to implement the foreach behaviour, if the cursor is at the foreach statement, and you press F10, instead of stepping into the first line of the loop inner as usual, since theopApply
is essentially just a function call, the debugger steps-over theopApply
and goes straight tonextLine()
.This gives the false impression that the collection is empty; but actually, the reality is that because
opApply
was a function call, it just stepped over the entire loop. SinceopApply
is rare, it's easy to miss/forget this detail, and so I find myself constantly making the improper assumption that the collection was empty, which occasionally leads down a rabbit hole chasing other explanations for a problem...I have no idea how to fix this; it seems like a hard problem... but I wonder if any creative solutions are possible?
Maybe a breakpoint could silently be placed at the entry to the loop-body lambda when the user presses step-over; but it's hard to imagine how to detect the conditions to enable a hack like that.
I guess there could be a solution that involves aggressive/forceful inlining of the
opApply
and the lambda?The text was updated successfully, but these errors were encountered: