Interpreter: rewrite async generator as a lazy coroutine (#690/#717/#752/#734)

[nickna]

Summary

Rewrites the interpreter's async generator from the eager full-body drain model to a lazy, main-thread C# async coroutine backed by an ECMA-262 §27.6.3 request queue. This single rewrite closes four open interpreter issues that all stemmed from the eager-drain model, and removes a class of environment-leak workarounds.

Why a coroutine, not a worker thread

The synchronous generator (SharpTSGenerator) suspends a background thread at each yield. That isn't viable for async generators: the interpreter is single-threaded — a custom SynchronizationContext routes every async continuation back to one event-loop thread — and a worker thread would race the event loop on the shared _interpreter.Environment. So the async generator body now runs as an ordinary interpreter async execution (ExecuteBlockAsync) on that event-loop thread and suspends at each yield by handing the value to the driving request and awaiting the next one.

Reusing the real async execution path is what fixes #717 and #752 essentially for free — a for await inside the body and an await nested in a yielded expression are handled by the same code that handles them in any async function.

Issues fixed

Issue	Before (interpreter)	After
#690 concurrent next()	Runtime Error: Only instances and objects have properties	FIFO request queue → 1 false 2 false
#717 for await…of inside an async generator	Runtime Error: Cannot iterate over non-iterable value	drives the async-iterator protocol natively
#752 yield f(await x) closure leak	outer binding reads back undefined (undefined 2)	environment preserved across the nested await (T 2)
#734 async generator expression capturing a block-scoped binding	Error: Undefined variable 'n'	runs natively; compiler still errors cleanly

How it works

• SharpTSAsyncGenerator (full rewrite): states SuspendedStart / SuspendedYield / Executing / Completed; a Request queue of next/return/throw (each carrying a TaskCompletionSource). The body is started lazily on the first next() (synchronously up to its first suspension, matching the spec) and suspends at each yield via SuspendAtYieldAsync. return()/throw() reuse the synchronous generator's GeneratorResume / GeneratorReturnException injection, so finally blocks run.
• Interpreter.CurrentAsyncGenerator identifies the active generator. Expr.Yield in the async path routes through the new EvaluateYieldAsync → OnYieldAsync (the yielded expression is evaluated asynchronously, so yield await x works).
• AwaitPreservingEnvironment now also saves/restores CurrentAsyncGenerator, so interleaved async generators never observe each other's binding.
• for await…of early exit (break / return / throw out of the body) now calls CloseAsyncIteratorOnEarlyExit — ECMA-262 AsyncIteratorClose — so a suspended generator runs its finally blocks before the loop leaves (a lazy generator is otherwise abandoned at its yield). Integrated with the labeled-loop adoption from Labeled for await...of is iterated synchronously (both interpreter and compiled) #728.
• Async generator function expression capturing a block-scoped binding is not supported (interpreter mishandles it) #734: EvaluateArrowFunction dispatches IsAsync && IsGenerator to a new SharpTSAsyncArrowGeneratorFunction; GeneratorArrowLifter drops the !IsAsync guard so a block-capturing async generator expression is left in place (the compiler reports the same clean "Yield not supported in this context" error as the sync Generator function expression capturing a block-scoped / loop variable is lifted out of scope #678 case).
• Re-entrancy: a next()/return()/throw() issued while the body advances itself synchronously rejects with a catchable TypeError: Async generator is already running rather than deadlocking (the interpreter analog of the compiled Compiled async generator re-entrant next() stack-overflows (needs request-queue semantics, not the sync 'already running' guard) #542 guard).

Tests

• Full suite green after rebasing onto current main.
• Promoted 7 previously CompiledOnly async-generator tests to run in the interpreter too (Compiled async generator: resumed yield (and yield* completion) evaluates to null instead of undefined #481 resumed-yield / yield* completion, Compiled async generator re-entrant next() stack-overflows (needs request-queue semantics, not the sync 'already running' guard) #542 re-entrancy, Compiled: for await…of INSIDE an async generator still blocks on a genuinely-async source (AsyncGeneratorMoveNextEmitter.EmitForAwaitOf) #697 for-await-inside-generator suspend / break / try-finally).
• Added a #734 region in GeneratorTests (interpreter-native + compiler-rejects-clearly) and a direct-next() Interpreter: async generator leaks its closure when an await is nested inside a delegated expression (yield f(await x)) #752 regression in AsyncGeneratorTests.

Notes for the reviewer

• Second commit unbreaks main's build. When I rebased onto current main, the tree did not compile: the two instance/private-method call sites of EmitGeneratorFunctionDCInit pass methodBuilder.GetParameters() (a ParameterInfo[]) to a parameter declared Type[]? — a latent mismatch from Compiled mode: async/generator private methods (async #m, *#m) emit invalid IL / unsupported #720 (which deliberately boxes from the method's actual IL signature) meeting Compiled: arrow inside an INSTANCE generator method that writes a captured variable (function DC not wired) #724/Compiled: arrow inside an ASYNC generator body that writes a captured variable (full function-DC fix) #725 after both landed. The fix accepts ParameterInfo[]? and boxes via .ParameterType; behavior is unchanged. It is a separate commit so it is trivial to drop if main is fixed independently.
• Interpreter: labeled loop containing await/yield fails in async functions and async generators #770 (labeled loop containing await/yield) is resolved — it turned out to be addressed by the combination of Labeled for await...of is iterated synchronously (both interpreter and compiled) #728 (which added an async labeled-statement handler and label adoption in the async loops) and this rewrite (which makes a yield in such a loop suspend). Closed.
• Interpreter: async generator re-entrant next() after a genuinely-pending await is not guarded (silent stall) #771 (a re-entrant next() issued after a genuinely-pending await isn't guarded → silent stall, not a hang) remains open as a pathological self-referential limitation.