1543225 - [jsdbg2] Debugger doesn't distinguish implicit await when an async function returns (just calls onPop twice)

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[Jim Blandy :jimb]

A Debugger.Frame's onPop handler gets called twice for the return of an async generator. The following program:

var g = newGlobal({ newCompartment: true });
g.eval(`async function* ag() { return 42; }`);

var dbg = new Debugger(g);
dbg.onEnterFrame = f => {
  print(`onEnterFrame: ${f.callee.name}`);
  f.onPop = function (k) {
    print(`onPop: ${uneval(k)}`);
  };
}
(async function () {
  const a = [];
  for await (let item of g.ag()) {
    a.push(item);
  }
  return a;
})().then(v => {
  print(`resolved to ${uneval(v)}`);
});

produces the following output:

onEnterFrame: ag
onPop: ({return:{}})
onEnterFrame: ag
onPop: ({return:42})
onEnterFrame: ag
onPop: ({return:42})
resolved to []

I would have expected to see 42 only once.

Comment 1

[André Bargull [:anba]]

return in async generators performs an implicit await per spec, basically as if return await 42 had been written: https://tc39.github.io/ecma262/#sec-return-statement-runtime-semantics-evaluation

So I guess the additional onEnterFrame/onPop pair is actually the implicit await.

Comment 2

[Jim Blandy :jimb]

Ah, okay, great. I was hoping it was something like that. I'm adding more detailed information to completion values in bug 1470558, so that should let consumers distinguish the implicit await from the final return.

Comment 3

[Logan Smyth [:loganfsmyth]]

Is this good to close?

Comment 4

[Jim Blandy :jimb]

Yes, I think we can close this.