Type checker: nested generator function declaration infers yield type as 'void' (ignores its yield expressions)

[nickna]

Summary

A generator function declaration nested inside another function has its yield type inferred as void, ignoring the yield expressions in its body. The same generator at the top level infers correctly.

Repro

function outer() {
  function* g() { yield 42; }
  return [...g()];
}
console.log(outer());

• Interpreter: prints [42] — runtime is unaffected (it ignores the inferred type).
• Compiled: Error: The type 'System.Void' may not be used as a type argument. — the inferred Generator<void> becomes an invalid IEnumerator<System.Void> in IL.

Annotating the return type works around the inference but then hits the separate compiled-lowering bug #501:

function* g(): Generator<number> { yield 42; }   // nested → "Compile Error: Yield not supported in this context" (#501)

Contrast — top level infers correctly

let y = 5;
function* g() { yield y; }     // inferred Generator<number>
console.log([...g()]);         // [5] in both modes

Notes

• Type-checker bug, independent of compilation: the inferred type is wrong (Generator<void> vs Generator<number>). It also produces spurious assignability errors, e.g. Type 'Generator<void>' is not assignable to type 'Generator<number>' when annotated as the latter.
• Found while fixing Type checker: generator function *expression* can't close over block-scoped (let/const) outer variables — 'Undefined variable' #522 (generator function-expression closures). The GeneratorArrowLifter lifts generator expressions to top-level declarations partly to stay on the working top-level inference path; this issue is one reason lifting them into a nested scope instead is not yet viable.
• Likely the return-type refinement pass that runs for top-level function declarations is not applied to nested function declarations.

[nickna]

Already resolved by 533d0cf (#548/#532): generator yield-type inference now draws from the yield/yield* operand types instead of the (void) inferred return type, so a nested generator declaration infers Generator<number> and the compiled path no longer emits an invalid IEnumerator<System.Void>. Verified the interpreter ([42]), the compiled path, and the assignability symptom (const x: Generator<number> = g() accepted; Generator<string> rejected). Regression coverage exists in GeneratorYieldInferenceTests (NestedGenerator_InfersYieldType_RunsInBothModes, NestedGenerator_InferredYield_SatisfiesAnnotatedReturn); #695 closes this.