Compiled generator: nested-block shadow of a closure-captured name still leaks (out of #711 scope)

[nickna]

Summary

The #711 fix disambiguates a nested-block let/const that shadows an enclosing binding by giving it its own storage — except when the shadowed name is also referenced by a nested closure (arrow/function/class) in the same generator. Those names are deliberately left untouched because the closure-capture machinery keys captured variables by source name and the #711 rename does not rewrite closure interiors; renaming a captured name would desync the capture. So this residual case still leaks.

Repro

function* g(): Generator<number> {
  const r = 100;
  {
    const r = 5;
    const f = () => r;   // arrow captures the inner r → name "r" is off-limits to the #711 rename
    yield f();
  }
  yield r;
}
console.log([...g()]);

• Interpreted: [5, 100] (correct)
• Compiled: [5, 5] (wrong — outer r leaked to 5 via the shared field/DC)

Notes

A proper fix needs precise per-binding capture analysis (which arrow captures which lexical binding) so a shadowing binding can be renamed and its capturing closures updated consistently — rather than the current conservative "skip if the name appears in any closure" guard in GeneratorBlockScopeRenamer. Astronomically rare; low priority. Found while implementing #711.

[nickna]

Investigated alongside PR #798 (which closed #766 and #768) and intentionally deferred there.

Pinpointing the blocker for a future fix: ClosureAnalyzer records captures program-wide and by source name (Dictionary<object, HashSet<string>> of lexemes; _allCapturedVariables is a global name set), and the display-class field maps are name-keyed too. The #711 GeneratorBlockScopeRenamer is, by contrast, a per-state-machine, emit-time, node-keyed token rewrite that deliberately does not touch closure interiors.

So renaming a closure-captured shadow (e.g. inner const r = 5 captured by const f = () => r) requires the rename to propagate into ClosureAnalyzer's capture set, the display-class field generation, the capture population (snapshot), AND the closure-body read — all consistently. That is a broad-blast-radius change to a foundational, program-wide pass for an astronomically-rare case, so it stayed out of #798's scope. The current conservative guard (skip renaming any name referenced by a nested closure) keeps #766/#711 sound; this residual leak is the documented trade-off.