Preserve loop iteration state across suspensions in async generators and for-await-of

[HermanusMuellerEU]

Summary

Fix for...of/for await...of losing per-iteration state when the loop body
suspends in async generators and async functions.

Details

Two related defects in how JintForInForOfStatement preserves per-iteration
state across a suspension, both reproducing on every release tested (4.9.3 →
4.14.0) and current main.

1. for...of + yield/await inside an async generator — infinite loop:

​js async function* gen(arr) { for (const x of arr) { yield x; } } for await (const x of gen(['a', 'b', 'c', 'd'])) { console.log(x); // a, b, b, b, b, ... forever (Node prints a, b, c, d) } ​

2. for await...of + a plain await in the body — every item dropped:

​js async function* source() { yield 'a'; yield 'b'; } const seen = []; for await (const x of source()) { await Promise.resolve(); seen.push(x); } // seen is [] under Jint ([a, b] under Node); same in async generators ​

We hit both in a real workload (a large async-heavy codebase running under
Jint): the first presents as a silent 100%-CPU hang, the second as data that
was verifiably written being reported as "not found" (a lookup's result stream
came back empty).

Root cause

BodyEvaluation saves per-loop suspend state (the live iterator, current
value, iteration env) before executing the body — but only for sync
generators (ExecutionContext.Generator) and async functions
(ExecutionContext.AsyncFunction), and only for sync iterators. The resume
path in ExecuteInternal reads through ExecutionContext.Suspendable, which
covers async generators too — so:

• In an async generator, ExecutionContext.Generator is null and nothing
  is saved. Every resume finds no state, re-runs HeadEvaluation into a fresh
  iterator from position 0, the body's fast-forward consumes step 1 as the
  pending resume value, and the next real step re-yields element 2 — forever.
• For for-await-of, ForAwaitSuspendData.CurrentValue was only saved for a
  yield inside destructuring. When the body suspends at a plain await, the
  resume finds CurrentValue == null, clears IsResuming, and proceeds to
  await the iterator's next result — dropping the in-flight item; when the
  stream ends the loop completes as if it had processed everything.

The fix

• Mirror the existing async-function save block for async generators (sync
  iteration kind), and extend the current-value clear and accumulated-value
  bookkeeping the same way.
• For for-await-of in an async function or async generator, save
  CurrentValue/IterationEnv/LhsBindingComplete before the body runs, so a
  mid-body suspension re-enters the CURRENT iteration on resume (the existing
  CurrentValue is not null resume branch, extended to restore the iteration
  environment and skip lhs re-binding); clear it once the body completes
  without suspending so a later awaited-next() resume is not shadowed.
  LhsBindingComplete is added to ForAwaitSuspendData (same contract as the
  existing field on ForOfSuspendData).

No behavior change for sync generators, async functions over sync iterables,
destructuring-yield resumes, or non-suspendable contexts.

Linked issue

No existing issue covers this; happy to file one if preferred.

Test plan

• Added or updated unit tests in Jint.Tests —
  Runtime/AsyncGeneratorForOfTests.cs (new, 24 tests). Each drains its
  generator with an iteration guard so a regression fails loudly with a bounded
  wrong sequence (…,RUNAWAY / (EMPTY)) instead of hanging the run.
  Coverage: the two defects plus controls that must stay correct (index-based
  loop, no-suspension loop, sync-generator route, async-function route,
  for-await-of + yield route); await and yield suspension variants;
  Map/Set/string/one-shot-generator iterables; break/continue/
  early-return/nested loops/multiple yields and awaits per iteration across
  suspensions; empty and single-element iterables; accumulated values surviving
  suspension. Before the fix, 17 of the 24 fail; after, all 24 pass.
• Ran dotnet test --configuration Release locally — no new failures
  (identical failure set to unpatched main: 5 timezone-dependent
  DateTests.CanParseDate cases caused by this machine's tzdata).
• For ECMAScript spec changes: ran Jint.Tests.Test262 and confirmed no
  regressions (identical results to unpatched main: 99,439 passed; the 2
  failures are pre-existing intl402 timezone-canonicalization cases that fail
  identically on unpatched main on this machine).
• For interop changes: n/a
• For perf changes: n/a — suspend-state bookkeeping only runs in
  suspendable contexts; the non-suspendable fast path is untouched.

Breaking change?

No.

[lahma]

Thank-you!