1595986 - [jsdbg2] Force return completions are a weird special case currently as neither a termination nor an exception

Status: NEW

(Core :: JavaScript Engine, enhancement, P3)

Description

[Logan Smyth [:loganfsmyth]]

I came across this while investigating https://bugzilla.mozilla.org/show_bug.cgi?id=1556033 and I wanted to file it as something as motivation to think through this. With the way things are now:

• If the debugger forces a throw, e.g. by returning something like { throw: "thrown string" }, this behaves just like a traditional abrupt completion from the standpoint of JS execution which means that if the instruction is inside of a try/catch, then the exception is reachable inside the catch block. Similarly, it means that finally blocks will execute.
• It the debugger forces a return, e.g. { return: "returned result" }, it is treated as if control jumped straight to the end of the function, which skips catch/finally blocks. This makes it an exceptionally special case, which causes bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=1556033

It seems like we should consider if this is functionality we actually want. I can see a few possibilities:

1. Leave things as-is (as a difficult implementation special case)
2. Support return completions generally, but treat then like any other abrupt completion, running finally blocks and such, which potentially means they could be intercepted or overridden if the function has later yield, return, or throw calls.
   The only downside here being that JS code can't normally get a return abrupt completion from arbitrary opcodes, so it could cause issues in other ways? I assume it'd be fine for the interpreter and baseline interpreter, but harder to say for baseline codegen? Since we already have to support other arbitrary abrupt completions through, I'm hopeful.
3. Drop support for return completions anywhere except onPop. I guess here there is also the question of whether we'd want that in all onPop or if we'd want to ignore onPop for yield and await suspensions.
4. Drop support for return completions at all.

One interesting thing to note is that even if we did option 2 or 3, I think it would be easier to actually implement, and users could continue to emulate the current behavior by using return null to terminate the execution of the function, but then having their onPop handler force a return completion value. That also makes it clearer that with return null the debugger is truly terminating the function.