Implement finish (step-out) operation in debugger.

[zherczeg]

#617 should land first.

The finish operation requires to find the ExecutionState of the current function. The best idea I have is getting the FunctionEnvironment of the current state, and check its parent states until I find a different FunctionEnvironment. It works with try-catch and with, but does not work with eval, i.e. the debugger does not just exit from eval, but it also exits from the function called the eval. However this can be considered correct depending on how you want to handle this case.

Anyway if you have a better suggestion for this operation, please let me know.

[ksh8281]

Can I have a question?
What happened if there is yield or await while stepping out?

[clover2123]

These if conditional statements could be merged into one statement.

[clover2123]

BTW is it possible to put a breakpoint inside eval code except function invoked during eval execution?

[zherczeg]

When you are in the eval code (after parsing), you can put breakpoints in there because they are regular functions (they have their own source code and byte code). However the IDE part is not simple for that, because the name of eval code is the same and any number of evals can be executed. If the IDE opens a separate editor for each eval code, it can insert single breakpoints for them. E.g.:

arr = []
for (var i = 0; i < 20; i++)
  arr.push(eval("(function() { return i })"))
for (var i = 0; i < 20; i++)
  arr[i]();

This code creates twenty different functions with the same source code. Each has their own byte code and source code, so the IDE can set separate breakpoints for each of them (the IDE can open twenty editor tabs, but these editors are not backed by real files). Opening hundreds of tabs for the user can be difficult to understand, but that is another story.

Is this what you wanted to know?

[zherczeg]

Regarding yield / async the debugger should stop after the next instruction (similar to return) unless you prefer something different. There was an unhandled code path which prevented it, but I fixed it (and a new test is added).

[ksh8281]

Sounds cool!

[ksh8281]

LGTM

[clover2123]

I have one more question.
For the above case, when "finish" is executed on the global code debugger runs the program until the next breakpoint encountered inside gen() instead of finishing the program.
But from the description, "finish" is defined as follow.

finish : Continue running until just after function in the selected stack frame returns.

I'm wondering what is the correct operation when another breakpoint is met during the execution of "finish" command. Should we stop at the breakpoint or ignore it?

[zherczeg]

In my experience breakpoints always takes priority over anything. So if a breakpoint is encountered the execution stops regardless of the last command.

[zherczeg]

Note: we can do this differently of course, but this is my experience with debuggers.

[clover2123]

Your answer makes everything clear! Thanks.

[clover2123]

LGTM