Speculative @unboxed classification leaks orphan shared records

[jagguji]

Summary

The unionNode candidate pass for an @unboxed variant calls memberOf, which can call classify and register records before runtime-bucket validation has succeeded. When a later arm makes buildable = false, those speculative records remain in the shared registry even though the final prop falls back to string.

Minimal reproduction

type JsxElement = { __brand: "element" }

type Leaked =
  | { left: string }
  | { right: number }

export declare const LeakProbe: (props: { value?: Leaked }) => JsxElement

Run:

node src/cli.mjs --dir <fixture> --out <out> --from demo --report --no-install

Current result:

// LeakProbe.res
type props = {
  value?: string, // loose fallback
}

but generation also reports 2 unique types and writes an otherwise unreferenced SpeculativeUnboxedLeakTypes.res:

type speculativeUnboxedLeakValueConfigV1a2ot = {left: string}
type speculativeUnboxedLeakValueConfigV5p5js = {right: float}

Expected

A rejected speculative mapping must leave no registry or emission side effects. Either map Leaked faithfully or keep the fallback without emitting unused shared records/modules.

Root cause

memberOf is side-effectful for object arms. The if (buildable) candidate construction in unionNode is not wrapped in the registry snapshot/rollback used by other speculative builders, so failure on the duplicate object runtime bucket abandons already-registered records.

The same class of leak can also leave shared.usesJsFn set after a rejected candidate containing bare Function, causing an unused JsFn.res file.

Verified on main at 5afe64c and on PR #174 at 7b25189. A golden fixture should assert both the final prop and the complete emitted file set.

[jagguji]

Attempted in #183 and reverted — a bail-time rollback cannot work here, and the evidence is worth recording before anyone tries it again.

Why the obvious fix is wrong

Wrapping the @unboxed candidate pass in registryTrial does remove the orphans. It also removes types that later become genuinely reachable.

boundedPastDepth (src/extract.mjs:2853) treats an already-registered type as safe to materialise past MAX_DEPTH:

if (t.id != null && ctx.shared && ctx.shared.byKey.has('id:' + t.id)) return true // registered → link

So a speculative registration doubles as a cache: a later, legitimate reference that arrives deep in the traversal links to the existing entry instead of degrading. Un-register it at bail time and that later reference has nothing to link to, so it truncates.

Measured on blend 0.0.37 — PointOptionsObject is discovered speculatively, then reused from a real path:

-  options: pointOptionsObject<'a, 'b, 'c>,                                    ← field disappears entirely
-  optionsToObject: stringOrNumber…OrPointOptionsObject<'a,'b,'c> => Dict.t<JSON.t>,
+  optionsToObject: string => Dict.t<JSON.t>,  // ⚪ loose — was `PointOptionsType`

Same regression in point.options and update. Top-level bucket counts did not move, which is why my own verification passed it — the loss is inside shared records, not component props.

The design that would work

Keep the speculative registrations, and remove orphans in a reachability sweep after traversal completes:

1. root set = everything referenced from component props, function signatures, class members;
2. mark transitively through entry.deps;
3. drop unmarked entries (and un-set shared.usesJsFn if no surviving entry needs it).

That is strictly better than a rollback: it catches every orphan regardless of which builder created it, and it cannot damage a type that something ends up referencing, because reachability is only known at the end.

Two things to get right when implementing:

• The root set must include everything emit can reach, not just props — function bindings, class members, @set_index value types, opaque-module views. A too-narrow root set silently deletes live types, which is the same class of bug as the rollback but harder to spot.
• _heal and the relink passes run post-extraction too (healGhostRecords, stabilizeNames, syncRefTparams) — the sweep has to sit in the right order relative to them, and stabilizeNames' collision groups change if entries disappear, so name output may shift.

Related

usesJsFn is now snapshotted by registryTrial (#183) — correct for the builders that legitimately roll back, and reusable by the sweep.