[codegen] concreteClass propagation through closure capture breaks stage1 binary-type check

[cs01]

Context

Attempted fix for #640 Step 3b (setInterval capture segfault) in PR #644 — closed.

Real root cause (not as #640 describes): captured class instance in a closure loses its concrete class name → capturedVar.field can't find GEP → final load uses field's nominal type against whatever alloca holds. Pointer-typed fields segfault; number fields silently return garbage.

Minimal repro:

class T { h: string = "hello"; }
const t = new T();
setTimeout(() => { console.log(t.h); }, 10);

Prints garbage on main.

Attempted fix (failed)

Plumb concreteClass through ClosureAnalyzer + generateArrowFunction, re-bind captured locals with createClassMetadata instead of plain defineVariable (~60 LOC diff across 8 files).

Failed on stage1/2 regression: fixture semantic/binary-type-in-function (rejects "hello" - 5 with "cannot use '-' between 'string' and 'number'") started passing silently — no compile error emitted. Stage1 compiler built from modified source lost the binary-type-mismatch check somewhere in the re-bind path.

Next

Needs someone to diagnose why the re-bind logic in variable-allocator.ts/closure-analyzer.ts interacts with semantic binary-type checking. Likely the re-bind overwrites type metadata the type-inference pass depended on.

Branch step3b-setinterval-segfault closed; diff available via PR #644 history.

Blocks: #640 Step 3b completion.

[cs01]

Second attempt — same regression

Tried the "additive metadata" approach suggested in the issue: instead of defineVariableWithMetadata(..., createClassMetadata(...)) (PR #644's replacement strategy), call symbolTable.setConcreteClass(name, className) after the existing defineVariable(...) to only add the concreteClass field without touching any other symbol metadata.

Result: same [stage1] and [stage2] semantic/binary-type-in-function regression as PR #644. "Expected compilation to fail for binary-type-in-function.ts, but it succeeded" — the stage1 compiler (built by stage0 from my patched src) silently skips the binary-type-in-function compile-error emission.

Bisection notes

• Node compiler (stage0 built by node from patched src): correctly emits cannot use '-' between 'string' and 'number' on the fixture. Issue [codegen] concreteClass propagation through closure capture breaks stage1 binary-type check #646 repro also prints hello correctly.
• Stage1 (built from patched stage0): compiles binary-type-in-function.ts to a binary and exits 0 instead of emitting the compile error. Repro still prints hello.
• All toplevel binary-type fixtures (binary-type-string-minus, binary-type-object-plus, binary-type-bool-plus-number, binary-type-valid-ops) pass on stage1/2. Only binary-type-in-function (which triggers checkBinaryTypesDeep walking into function bodies) fails.
• checkBinaryTypesDeep in src/semantic/safety-checks.ts is a pure AST walk with no closures, no symbol-table dependency. It's called in llvm-generator.ts#generateParts alongside many other semantic passes. None of the other semantic passes regress — the miscompilation specifically lands on whatever codepath this one pass exercises.

Tried and still broken

1. defineVariableWithMetadata(..., createClassMetadata(...)) replacement (PR [codegen] propagate concreteClass through closure capture #644's approach).
2. Additive symbolTable.setConcreteClass(name, className) after defineVariable.
3. Changing getScopeVarsArraysForClosure return from 3-field to 4-field struct.
4. Keeping 3-field return and adding a separate getConcreteClassesForNames(names) helper.
5. Disabling the setConcreteClass call entirely while keeping the rest of the plumbing (struct-shape change + getter-simplification) — still regresses.
6. Full PR [codegen] propagate concreteClass through closure capture #644 cherry-picked onto latest main (425d51e) — same regression.

What's confirmed NOT the root cause

• setConcreteClass call in function-generator.ts (disabled, still regresses).
• symbol.concreteClass-then-classMetadata.className boolean chain (simplified, still regresses).
• Struct shape of getScopeVarsArraysForClosure return (both 3- and 4-field tested).

Hypothesis

Something in the cross-file plumbing interaction (closure-analyzer.ts + arrow-functions.ts + function-generator.ts + generator-context.ts interface extension) — even without any read/write of concreteClass — perturbs how stage0 compiles stage1's src/chad-native.ts such that checkBinaryTypesDeep loses a specific code path. Possibly: an unused-param addition to an interface method shifts GEP indices somewhere downstream, or the new optional parameter on generateArrowFunction/closure-analyzer.analyze interacts with native ABI for optional params in a subtle way.

Next debugging step

Full trace: run stage1 with printf instrumentation in checkBinaryTypesDeep and validateBinOp to confirm whether the pass runs at all on the fixture and, if so, what inferBinType(b.left) returns for "hello". If it returns "unknown" instead of "string", then the stage0-compiled AST of the fixture has a different expr.type string for string literals — pointing at a very different downstream miscompilation.

Stop conditions hit

• Multiple variants regress identically (main stop condition from the task prompt).
• Diff is only ~90 LOC but cannot ship without stage1/2 regression.

Closing PR #655. Branch issue-646-closure-class force-reset to main. No code landed.

[cs01]

Status update (2026-04-22): per #658, this bug class is the explicit motivation for Tier 1 step #1 (loosen isStableExprType to admit variable expressions so codegen reads typeOf cache instead of live-resolving). Re-binding via createClassMetadata (the failed approach in PR #644) is no longer the planned fix — annotator-cache propagation is. Leaving open as the validation target for that step.