Interpreter: labeled loop containing await/yield fails in async functions and async generators

[nickna]

Summary

In the interpreter, a labeled iteration statement (label: for/while/... {}) that contains an await or yield fails, because labeled statements have no async execution handler: RegistryDispatch.DispatchStmtAsync falls back to the synchronous ExecuteLabeledStatement, which runs the loop body via the sync Execute/Evaluate path. That path cannot suspend, so an await inside throws "'await' can only be used inside async functions" and a yield inside throws a raw YieldException.

Repro

// await inside a labeled loop in a plain async function
async function f() {
  outer: for (let i = 0; i < 2; i++) {
    for (let j = 0; j < 2; j++) {
      const x = await Promise.resolve(i * 10 + j);
      console.log("v" + x);
      if (j === 0) break outer;
    }
  }
}
f();
// Interpreter: Runtime Error: 'await' can only be used inside async functions.
// Node: v0

// yield inside a labeled loop in an async generator
async function* g() {
  outer: for (let i = 0; i < 3; i++) {
    for (let j = 0; j < 3; j++) {
      try { yield i * 10 + j; if (j === 1) break outer; } finally { console.log("fin" + i + j); }
    }
  }
}
async function main() { for await (const v of g()) console.log("v" + v); }
main();
// Interpreter: fin00 then "Runtime Error: ...YieldException..."
// Node: v0, fin00, v1, fin01

Compiled mode is correct for both (it has a full async-generator/await state machine). The plain (non-labeled) sibling loops work in the interpreter — only the labeled form falls back to sync.

Cause / fix direction

Two pieces are needed:

1. An async handler for Stmt.LabeledStatement (an ExecuteLabeledStatementAsync mirroring the sync ExecuteLabeledStatement but running the inner statement via ExecuteStatementAsync).
2. Labeled break/continue adoption in the async loop handlers (ExecuteForAsyncVT, ExecuteWhileAsyncVT, ExecuteDoWhileAsyncVT, ExecuteForOfAsync, ExecuteForInAsync). These currently only honor unlabeled break/continue (TargetLabel == null); they do not drain _pendingLoopLabels / carry LabelNames the way the sync loops do (Compiled: chained label on a for re-runs initializer on continue <outerLabel> (interpreter handles it) #580). Adding (1) without (2) would regress labeled loops that today work via the sync fallback (a labeled continue would propagate out of the loop instead of advancing it).

Notes

• Pre-existing; surfaced while rewriting the interpreter async generator to a lazy coroutine (which runs the body through the real async execution path). The compiled-only AsyncGeneratorTryFinallyTests.LabeledBreakToOuterLoop_RunsInterveningFinally / LabeledContinueToOuterLoop_RunsInterveningFinally cover the compiled side; the interpreter side is this gap.

[nickna]

PR #786 (fixing #728, labeled for await) implements exactly the two pieces this issue's fix-direction calls for — an async LabeledStatement handler (ExecuteLabeledStatementAsyncVT) plus labeled break/continue adoption (draining _pendingLoopLabels / honoring LabelNames) in ExecuteForAsyncVT, ExecuteWhileAsyncVT, ExecuteDoWhileAsyncVT, ExecuteForOfAsync, and ExecuteForInAsync.

With that PR:

• Async function case (this issue's repro): fixed — outer: for { for { await …; break outer } } now prints v0.
• Async generator case: no longer throws the raw YieldException, but a labeled continue/break inside an async generator can still drop subsequent yields because of the pre-existing eager-drain behavior (Interpreted async generator: body side effects run out of order vs for-await-of consumer (eager drain) #564) — e.g. outer: for(i) { for(j){ if(j===1) continue outer; yield i*10+j } } yields only 0, instead of 0,10,20,. So the async-generator half remains gated on Interpreted async generator: body side effects run out of order vs for-await-of consumer (eager drain) #564.

Leaving this open for the async-generator residual; the async-function half is resolved by #786.

[nickna]

Resolved by the combination of #728 (which added `ExecuteLabeledStatementAsyncVT` plus labeled break/continue adoption in the async loop handlers) and the lazy async-generator coroutine rewrite in #773.

Verified on the merge of both:

// await inside a labeled loop in a plain async function (was #728)
async function f() {
  outer: for (let i = 0; i < 2; i++) {
    for (let j = 0; j < 2; j++) {
      const x = await Promise.resolve(i * 10 + j);
      console.log("v" + x);
      if (j === 0) break outer;
    }
  }
}
f();
// -> v0

// yield inside a labeled loop in an async generator (needed both: #728 routes the
// labeled loop to the async path, the coroutine rewrite makes the yield suspend)
async function* g() {
  outer: for (let i = 0; i < 3; i++) {
    for (let j = 0; j < 3; j++) {
      try { yield i * 10 + j; if (j === 1) break outer; } finally { console.log("fin" + i + j); }
    }
  }
}
async function main() { for await (const v of g()) console.log("v" + v); }
main();
// -> v0, fin00, v1, fin01

Both now match Node. Closing.