Infer a bare variant's instantiated owner from the expected type, not its declaration node

[gunbai-bot]

What

A bare variant reference inferred as its owner coproduct's declaration node, whose children are the coproduct's arms rather than type arguments. type Optional<T> = Absent | Present { value: T } declares Absent as child 0, so a generic owner reaching the renderer uninstantiated rendered Option<Absent> — a constructor in type position, not a Rust type.

The emitter was rendering faithfully what inference handed it. The fix is in v1.compiler.infer: when the context supplies an expected type that owns the variant, that expected node is the instantiated owner, so it is adopted in place of the declaration node. The same lookup already existed in the unresolved-name arm; it is hoisted to one authority so a variant that resolves gets it too, rather than only one that does not.

Measured — emitted v2.compiler.05_eval closure, before → after

	before	after
Option<Absent> sites	21	0
rustc errors	494	473
per-code delta	—	−19 E0425, −2 E0573; no code increased
self-host fixed point	—	green (two generations)

Whole-artifact diff is 24/24 lines, fully accounted: 21 broken annotations repaired, 2 improved to concrete types (Option<Rc<UriPercentEncodeRefusalCause>>, Rc<NamedEdgeTargetLookup> — a bare Absent of a user coproduct, same class), 1 Verdict annotation relaxed to _.

Baseline sites: 17 v2_compiler_body_lowering_fold, 2 v2_compiler_infer, 2 v2_std_cardinality.

Adoption is narrow on two axes, both earned by a failure

Identity — only when the expected type's own head names the coproduct resolution already bound, so this instantiates the owner the binder chose rather than re-targeting to a different coproduct declaring an arm of the same name (Absent is an arm of Optional, ObservationVerdict and ConvergeVerdict alike).

Cardinality — only when the expected node is Required. Optionality is not a wrapper type here: BinOp? is a BinOp node whose return_cardinality is CardOptional, so a head comparison cannot see it. For binop: Mod against BinOp? the head is BinOp and the arm is found, but the constructor's type is BinOp and the optionality is a coercion the emitter performs by wrapping. Adopting there made the value look already-optional and emitted binop: BinOp::Mod where Some(BinOp::Mod) is owed.

Why that regression survived every instrument but one

Two successive drafts shipped the wrapper loss across four extdeps.languages.*_syntax modules and std.effects. The Option<Absent> count, the whole-artifact diff, and the rustc census all stayed green through both — because all three measure the eval closure, and the damage was in v1's own emitted sources. regen_stage0 --verify was the only instrument whose subject included it. A population that cannot disagree cannot falsify.

Witness

Enrolls the cardinality half, which is single-source constructible and is the half both wrong drafts broke, with a required-field positive control so the repair is not satisfiable by wrapping everything or by refusing every adoption. Both rows green by execution; both assertions verified against real emitted bytes first.

The headline Option<Absent> case has no enrolled row, and the note says so rather than leaving it to be discovered: it needs the v2 Optional coproduct as a declared generic type and an ambiguously owned arm name, but Optional is not declared anywhere in the dag corpus (it is the built-in T? sugar), and two same-named arms in one module are refused outright. Its evidence is the executed corpus measurement above — discriminating, but not recurring.

Rung, honestly

Mitigatable, not structural. With no expected type, inference still falls back to the declaration node, so a declaration-shaped node can still reach a type position — the bad state remains writable.

Dissolve-on: constructor ownership and constructor value type become separate facts with a needs-context / refused arm, at which point a declaration node has no route into a type position and this guard is replaced by unwritability.

🤖 Generated with Claude Code

[gunbai-bot]

One correction to the record, since acting on it would red the seed.

The review reads the extdeps_uri.rs closure-parameter annotation as "unrelated ... trivially benign". It is neither unrelated nor optional: it is this change's own output, and it is load-bearing.

- |acc: _, outcome: Rc<UriPercentEncodeScalarOutcome>|
+ |acc: Option<Rc<UriPercentEncodeRefusalCause>>, outcome: ...|

That is the instantiation firing on v1's own emitted sources — the fold init is a bare variant whose owner is now instantiated from the expected type instead of left as a declaration node. Because regen_stage0 re-emits the seed, the committed stage0 must already contain what the new compiler emits. Dropping this hunk as churn makes regen_stage0 --verify red and the self-host fixed point unreachable; it took a second bootstrap generation to fold in, and the gen-2 verify is what turned green.

Worth flagging because it generalises: on a compiler change, a diff hunk in src/v1/stage0/src/** that looks incidental is usually the fix's output rather than noise, and the fixed point is the thing that decides.

Related, and the reason I am confident about it: the fixed point caught this repair being wrong twice while every other instrument stayed green. Both earlier drafts dropped Some(...) on optional fields across five v1 modules. The Option<Absent> count, the whole-artifact diff, and the rustc census (494 → 473, no code up) all measure the emitted eval closure — which does not contain v1's own sources, so none of them could have disagreed.

No change requested; the review's verdict stands. Recording it so the hunk is not tidied away later.

— sent from gentle-dove-833

[gunbai-bot]

Recording two adjacent findings raised in review-adjacent analysis, with dispositions, so neither is silently absent.

1. The witness does not cover the generic-owner repair. Correct, and declared rather than discovered: the witness note says so explicitly and gives the reason. The headline Option<Absent> case needs the v2 Optional coproduct as a declared generic type AND an ambiguously-owned arm name, but Optional is not declared anywhere in the dag corpus (it is the built-in T? sugar), and two same-named arms inside one module are refused outright by the compiler — so compile_dag_rust_emit_check, which compiles ONE synthetic source, cannot construct the subject. Its evidence is the executed corpus before/after (21 -> 0 sites, 494 -> 473 rustc errors, no code increasing), which is discriminating but not recurring. The enrolled half is the cardinality half. That asymmetry is the honest coverage statement, not an oversight.

2. The expected-context-only arm bypasses the new guard. Also accurate as a description. Where the name misses locals, func sigs and global bindings, the arm adopts the PEELED exp_enum and derives parent_enum from it, with no Required check. Two facts decide what to do about it:

It is pre-existing. This diff only extracted the inline lookup into expected_variant_owner_instantiation; that arm's semantics are unchanged, byte for byte. It is not a regression introduced here.

Applying the guard there would be wrong. At levels 1 and 3 the guard falls back to a real binding, so refusing adoption is free. At this arm there is NO binding — the expected type is the only source of truth, and the failure path is ambiguous_reference_refusal or a hard not-found. Adding a Required condition would convert currently-resolving programs into refusals. A fabricated refusal is forbidden by the same section as a fabricated success, so the symmetric-looking fix is the unsafe one.

The correct repair shape, if a live occurrence is found, is therefore NOT to refuse but to preserve cardinality — preserve_outer_optional_cardinality(outer: exp, inner: exp_enum) already exists in v1.compiler.core for exactly this — which keeps resolution AND keeps the wrapper.

I am not making that change in this PR, deliberately. I have no observed live occurrence: the self-host fixed point is green over two generations and whole-corpus emission differs only in the 24 lines already accounted for, so the arm is not firing destructively on any current site. Changing a resolution-critical arm on a hazard I cannot exhibit, with no discriminating control, is speculative hardening of precisely the kind that cost two wrong drafts here already — both of which were green on every instrument except the fixed point. It belongs in a follow-up carrying its own witness, and it is recorded here rather than left to be rediscovered.

— sent from gentle-dove-833

[gunbai-bot]

One correction to the record on review 52943, because it would close a finding that is still open.

That review states the identity axis as:

authored_name_at(exp) == owner_name prevents retargeting to a different coproduct that merely shares an arm name.

It does not. A name comparison is precisely what PERMITS that case. Given a.Status = Ready | AOnly and b.Status = Ready | BOnly, a Ready bound from a.Status against an expected b.Status passes the guard, because both owners are spelled Status and both declare a Ready arm. Review 52880 raised exactly this, correctly, and it is not fixed.

The hazard is real, introduced by this PR, and deliberately shipped. Commit 2 attempted the identity fix and is reverted in commit 3 with the measurement:

whole-corpus compile (dag + src/v2), one instrument, three arms
  origin/main              incompatible-types  0    undefined-variable 32
  commit 1 (shipping)      incompatible-types  0    undefined-variable 32
  commit 2 (identity)      incompatible-types 16    undefined-variable 32

The 32 undefined variable rows are pre-existing on main and are the control proving the read discriminates. Two identity formulations failed in opposite directions: comparing declaration spans raw silently reverted the repair to its full 21-site baseline (expand_scrut_type_for_variant_lookup returns a USE-SITE node once the connective is Disj, so a span comparison never matches), and normalising both sides through lookup_type_for restored the repair but adopted through aliases and qualified spellings that the name comparison declines — hence the 16.

So the accurate statement of what ships is: the identity axis is a name comparison, it does not establish identity, and the retargeting hazard it admits is open. It is narrow (needs two same-spelled coproducts sharing an arm name, one imported and the other the expected type) and unobserved in the corpus — whole-corpus emission differs from baseline only in the accounted lines. That is a measured bound, not a proof of absence.

I would rather ship the weaker guard with the hazard documented than the stronger guard that breaks 16 sites, but the finding is DEFERRED, not resolved, and a review artifact asserting the guard prevents retargeting is the one thing that could make it disappear quietly.

Also worth flagging for anyone reading the approvals: they were given against the diff, while the head now carries an auto-heal commit whose parent is a merge of this branch into main — so the branch silently acquired 62 changed files under src/v2/dag plus src/v1 changes. I am re-running the fixed point, whole-corpus compile, eval emission and witness against that merged state rather than relying on measurements taken at the original base; fixed point is already green on it.

— sent from gentle-dove-833