Fix #488, #534, #634, #635: generator expressions in more positions; async function expressions

[nickna]

Completes #488, #534, #634, #635.

#635 — Parse async function expressions

async function () {} and async function* () {} in expression position now parse. The parser previously only attempted an async arrow after async (it unconditionally consumed (), so any async function expression was a parse error. Added a function-keyword check that defers to the shared FunctionExpression parser (now isAsync-aware, and it already handles *), mirroring the statement-level async function declaration path.

GeneratorArrowLifter — complete, identity-preserving traversal

GeneratorArrowLifter rewrites generator function expressions into top-level Stmt.Function declarations so the mature generator-declaration IL pipeline can lower them. Its hand-rolled traversal covered only a subset of AST nodes, so a generator expression in an un-visited position was never lifted — and because the function-expression generator context is established only via the lift, the type checker then rejected its yield. The rewriter now descends through every expression- and statement-bearing position (identity-preserving, so untouched subtrees keep their node identity for the type checker).

• Generator function expression in IIFE/call position: 'yield' not recognized #488 — descends through grouped / call-position callees, so an IIFE generator (function* () { yield 1; })() is lifted and runs. ✅ both modes
• GeneratorArrowLifter does not recurse into for/for-of/for-in/do-while/try/switch/labeled statements (generator function expression in those contexts fails to type-check) #634 — descends into for / for-of / for-in / do-while / try-catch-finally / switch / labeled-statement bodies (plus ternary, array/object literals, new, spread, await, template literals, etc.). ✅ both modes
• Generator function expression nested in a function can't close over the enclosing function's locals (lifted to module scope) #534 — a generator expression closing over an enclosing function's body-level local is lifted into that function (keeping the local in lexical scope) instead of to module scope. The interpreter runs nested capturing generators natively; the compiler emits the pre-existing Compiled: nested generator function declaration inside a generator body fails to compile ('Yield not supported in this context') #501 "Yield not supported in this context" error, so the success path is interpreter-only (matches the issue's suggested interpreter-only improvement). A conservative free-variable analysis over-approximates the bound set, guaranteeing no false-positive nested-lift that would relocate a module-closing generator into a function and regress the compiled Type checker: generator function *expression* can't close over block-scoped (let/const) outer variables — 'Undefined variable' #522/#1295 closure cases.

Tests

• New AsyncFunctionExpressionTests (anonymous/named/IIFE/awaited/callback async function expressions + async generator expression for await).
• New GeneratorTests regions for Generator function expression in IIFE/call position: 'yield' not recognized #488 (IIFE/spread), GeneratorArrowLifter does not recurse into for/for-of/for-in/do-while/try/switch/labeled statements (generator function expression in those contexts fails to type-check) #634 (each loop/try/switch/labeled body), and Generator function expression nested in a function can't close over the enclosing function's locals (lifted to module scope) #534 (closure over function local / parameter, by-reference capture — interpreted).
• Full SharpTS.Tests suite green (12,716 passed); TypeScript conformance green (31).

Follow-up issues filed

• Generator function expression capturing a block-scoped / loop variable is lifted out of scope #678 — generator expression capturing a block-scoped / loop variable (the block-scope sibling of Generator function expression nested in a function can't close over the enclosing function's locals (lifted to module scope) #534; no single lift position works — append breaks block-fn hoisting, prepend breaks block-let TDZ).
• Named generator function expression loses its self-reference name (GeneratorArrowLifter) #679 — named generator function expression loses its self-reference name on lift (function* foo(){ … foo() … }).
• .call/.apply/.bind not supported on async functions (interpreter: 'undefined is not a function') #681 — .call/.apply/.bind unsupported on async functions (pre-existing; surfaced via Parser: async function expressions (async function () {}) are not parsed #635).
• Compiled for await...of over an async generator throws InvalidCastException (cast to IEnumerable) #680 was filed for the compiled async-generator for await crash, then closed as a duplicate of Compiler: for await...of over an async generator inside an async arrow emits synchronous IEnumerable iteration (InvalidCastException) #430/Compiled: or await over an async generator inside an async ARROW function throws InvalidCastException (lowered as sync for-of) #645 — that fix landed on main during this work, so async function* expressions now run in both modes.

Note on Test262

async function expressions let the whole Array/fromAsync/* Test262 suite parse (it uses asyncTest(async function () { … })); those ~76 tests move ParseError → Fail (a parser progression — they fail only because Array.fromAsync is unimplemented). The Test262 baseline is not updated here: local regen is non-deterministic in this Windows environment (unrelated tests flip Pass/Fail/RuntimeError run-to-run, plus intermittent host crash 0x80131506), so a regen would bake in noise. Test262 is not a CI gate; recommend regenerating its baseline in a stable environment.