flaky: capture-bearing class factory reports .name === undefined on some builds (build-nondeterministic)

[proggeramlug]

Summary

#6470 (be2e23f86, "per-evaluation captures for class declarations in function bodies") regressed class .name for a captured-param class-declaration factory. A named class declared inside a factory function that captures an outer parameter now reports .name === undefined instead of its declared name.

Repro

function makeTagged(tag: string) {
  class Inner {
    readonly _tag = tag;          // captures the outer `tag` param
    who() { return "tagged:" + this._tag; }
  }
  return Inner;
}
const T = makeTagged("S");
console.log(JSON.stringify(T.name));  // node: "Inner"   perry(main): undefined
console.log(new T().who());           // node: "tagged:S"  perry: "tagged:S"  (construction is fine)

Construction, the captured field, and method dispatch all work — only .name is lost. Covered by the existing gap test test_gap_5952_mixin_factory_binding (case 7), which now fails on main.

Bisect

• PASSES at b4b47ba34 (parent of fix(hir): per-evaluation captures for class declarations in function bodies (#6465) #6470)
• FAILS at be2e23f86 (fix(hir): per-evaluation captures for class declarations in function bodies (#6465) #6470) and every commit since (confirmed on current main)

Mechanism

For a capturing class declaration with no static state, #6470 sets fresh_binding = true and binds the name to a ClassExprFresh per-evaluation object (lower_decl/body_stmt.rs). The fresh object gets the right class_id (so methods/construction work), but its class_id is never entered into the CLASS_NAMES registry: name registration (codegen/string_pool.rs → js_register_class_name) only fires for class_ids collected into named_classes, and this fresh-factory template ends up excluded (classified anon / name-mismatched). .name then resolves via class_name_for_id(class_id) → None → undefined. Named class expressions through the same ClassExprFresh machinery keep their name, so the gap is specific to the declaration route + the specialize_captured_class_factories interaction.

Impact

Blocks conformance-smoke (shard containing test_gap_5952) on every PR branched off current main — surfaced while merging #6476 (unrelated streams PR). Mixin/class-factory patterns that read .name (incl. effect-style tagged classes) are affected.

[proggeramlug]

Correction — #6470 is NOT the culprit. I re-verified: the lowered HIR and the js_register_class_name codegen for test_gap_5952 are byte-identical at b4b47ba34 (#6459, PASSES) and current main (FAILS) — same Tagged = ClassRef("Inner"), same cid 11 → "Inner" registration. So this is a runtime regression, and #6470 (a HIR-only lower_decl/body_stmt.rs change that produces identical HIR here) cannot be it.

The regression is a runtime change in the range (#6459 .. current main]. Ruled out by scope: #6464 (buffer_dispatch only), #6457 (intl/icu4x only), #6470 (HIR-only). Remaining suspects: #6474 (class_constructors.rs + codegen/method.rs, "default Error-init on every dynamic construct path") and #6466 (init-call topo ordering). Bisecting now.

Symptom precisely: Tagged resolves to ClassRef("Inner") (class_id whose name IS registered as "Inner"), construction + methods work, but the runtime .name read returns undefined. So the break is in how .name resolves on a class-ref value / a captured-factory class at runtime.

[proggeramlug]

Second correction — this is a build-variable flake, not a clean regression, and NOT #6474 either.

After deeper testing the bisect does not hold up as a code regression:

• test_gap_5952 (and a 2-line repro function f(t){ class Inner { x = t } return Inner } f("S").name) fails on current-main local builds (undefined vs node "Inner"), reproducibly within a given compiler binary (5× identical .o).
• But it passed on the CI builds of the PRs merged earlier today (their conformance shards 2–8 were green, which includes this test's shard), and a no-capture variant (class Inner { x = 1 }, no factory param) always passes.
• Different compiler builds of the same commit produced different results for the capturing-factory case.

So the pass/fail tracks the compiler build, not the source commit — a build-order-nondeterministic latent bug in how a capture-bearing class factory (class declared in a function body that closes over a param) resolves its .name at runtime. #6470/#6474 are cleared.

Root cause is in the runtime per-evaluation capture path (the class the factory returns resolves to a class_id whose name registration is order-dependent), NOT the HIR display-name recording — I tried recording class_display_names for function-body class declarations in lower_decl/body_stmt.rs and it did not fix it, confirming the break is downstream in the capture/cid resolution.

Repro files + the (ineffective) HIR patch attached in the investigation. Needs someone with RegisterClassCaptures / per-eval-capture context. Marking as a flaky/nondeterministic gap failure.