Type checker: spreading a generator METHOD's result is rejected (return type inferred as '<inferred>', not iterable)

[nickna]

Summary

The type checker infers a free generator function's call result as iterable, but a generator method's call result is left as <inferred>, so spreading (or any iterable use of) it is rejected:

function* freeGen() { yield 1; yield 2; }
console.log([...freeGen()].length);       // OK → 2

class C { *m() { yield 1; yield 2; } }
console.log([...new C().m()].length);     // Type Error
// "Spread expression must be an iterable type (array, iterator, set, map, string, or generator),
//  got '<inferred>'."

The same applies to for (const x of new C().m()) only working because the iterator protocol is checked structurally there, whereas spread/Array.from go through the stricter iterable-type check.

Cause (likely)

The return type of a *method() isn't being resolved to Generator<…>/IterableIterator<…> the way a top-level function* is — it surfaces as <inferred>. The iterable check in the spread path then fails. (Interpreter and compiled execution both handle the value correctly at runtime — this is purely a static-typing gap.)

Workaround

Iterate with for…of and accumulate, or annotate the method's return type explicitly (*m(): Generator<number> { … }).

Discovered

While smoke-testing generator changes (#435/#669). Independent of those fixes.

[nickna]

Already fixed on main. Spreading a generator method's result type-checks and binds the element type correctly in both modes:

class C { *m() { yield 1; yield 2; } }
console.log([...new C().m()].length);     // 2

const x: string = new C().m();            // Type 'Generator<1 | 2>' is not assignable to type 'string'

The call site reads the real Generator<…> rather than <inferred> — this was resolved by the #658/#661 inferred-method-return propagation (PR #695, which post-resolves the method's inferred return during the class body pass and re-publishes the frozen class). It is covered by existing tests in GeneratorYieldInferenceTests (GeneratorMethod_InferredYield_IsIterable_RunsInBothModes, GeneratorMethod_InferredYield_WrongElementUse_Rejected, GeneratorMethod_InferredYield_ForOf_RunsInBothModes).

#750 only refreshes a stale comment in TypeChecker.Statements.Classes.cs that still claimed the inferred method return was unobservable at the call site, and tags the existing test with this issue number.

(Note: compiled static generator methods — class C { static *gen() {} } — still fail with "Yield not supported in this context", but that is a separate codegen gap tracked by #692, independent of return-type inference.)