Ground variant owner by expected type at each call site (§3: single authority)

[gunbai-bot]

Summary

Fixes the latent §3 collision flagged as residue in #5879: when a variant name appears in two coproducts that are BOTH in scope (e.g. `WriteThenCommit` ∈ `AtomicityModel` ∩ `CacheWriteSemantics`), the correct owning enum at each emit site is determined by the declared expected/field type at that site — not by scope-order or alpha-sort.

Authority site: src/v1/04_infer.dag — expected_type_override_enum helper added at line 515; ExprVar branch updated to call it. The .rs seed (v1_compiler_infer.rs) is hand-synced (not full-regen — correct per emitter-nondeterminism constraint).

What changed

src/v1/04_infer.dag (AUTHORITY) + v1_compiler_infer.rs (hand-synced mirror) — infer_expr ExprVar branch:
When the scope binds a shared variant to enum A (by import-order or alpha-sort), but:

1. The declared expected type at the call site is a different enum B, AND
2. B is a Disj type that also contains this variant

…then enum B is used as the owner. Both binding_kind (→ VariantValueBinding { parent_enum: B }) and the inferred resolved type are updated in lockstep, so the emit path in effective_variant_parent sees a consistent owner.

This is §3 single-authority grounding applied to variant-constructor sites: the EXPECTED TYPE is the authoritative single source, not whichever enum happens to be first in the scope map.

dsl/test/claim/variant_owner_expected_type_test.dag — floor-auto-enrolled .dag discriminating witness:
expected_type_picks_variant_owner_not_alpha_order(): AEarlyOwner and ZLaterOwner both define SharedVariant; make_z_variant() -> ZLaterOwner { SharedVariant } must infer ZLaterOwner as owner. Without the fix, scope-order picks AEarlyOwner → TypeMismatch → red. Verified green-by-execution.

variant_owner_disambiguation_test.rs — two new §2 .rs witnesses:

• shared_variant_resolves_by_expected_type_not_alpha_order: alpha-first default would pick the wrong owner; expected type overrides it. Red-on-revert.
• shared_variant_resolves_per_site_independently: two functions with different declared return types in the same module each get the correct owner — proves the fix is per-site, not per-module.

Concrete corpus case fixed

In dsl/extdeps/cache/github_actions.dag:

write_semantics: WriteThenCommit   # field type: CacheWriteSemantics → emits CacheWriteSemantics::WriteThenCommit ✓
atomicity:       WriteThenCommit   # field type: AtomicityModel       → emits AtomicityModel::WriteThenCommit ✓

Previously both emitted AtomicityModel::WriteThenCommit (alpha wins) — the write_semantics field was wrong.

---

Open residual (tracked, dissolution-gated)

Genuinely-ambiguous sites — expected=None → scope-order fallback (unchanged #5879 behavior):

When the expected type is None (e.g., variant used inside an anonymous record literal where record_lit_expanded_from_expected returns none for type_name=Absent), the override does not fire and the code falls back to scope_parent — the alpha-first enum via binding.resolved. This is the same deterministic scope-order behavior as #5879.

Classification: §5 "wall-after-grounding" — decidable but gated on a corpus migration. The strict fix (TypeAmbiguous diagnostic when expected=None and variant is shared) would break existing anonymous-record sites. Interim behavior is latent-safe: emit-host MVP smoke is green, emitted Rust is self-consistent.

Dissolution trigger: corpus migration to named struct literals or qualified variant syntax at ambiguous sites (e.g. CacheInterfaceCatalogIoSemantics { write_semantics: WriteThenCommit } instead of bare { write_semantics: WriteThenCommit }). Once migrated, the TypeAmbiguous wall can turn on without breaking anonymous-record sites.

---

Test plan

• shared_variant_resolves_to_locally_defined_owner_not_transitive (§1 — existing, still green)
• shared_variant_resolves_by_expected_type_not_alpha_order (§2 new — red without fix)
• shared_variant_resolves_per_site_independently (§2b new — red without fix)
• expected_type_picks_variant_owner_not_alpha_order (.dag floor witness — red without fix)
• CI green at 61d6812b — compile-clean + emit-host MVP smokes pass
• cargo fmt --check passes
• cargo clippy -p v1-compiler -- -D warnings passes

🤖 Generated with Claude Code

[gunbai-bot]

Req 5 — genuinely-ambiguous-site fallback: stated

When expected = None (or the expected type is not a Disj containing the variant), expected_type_override_enum returns Absent and the ExprVar branch falls back to scope_parent — the enum returned by lookup_variant_parent_enum. That function resolves to authored_name_at(binding.resolved), which is the first coproduct in source-order that contains the variant (the same alpha-sort anchor #5879 established for the scope-level case).

Why this is the correct residue (not a §5 hole):

The fix grounds every site where the expected type IS propagated — function return sites, named struct field sites where record_lit_expanded_from_expected fires. The genuinely-ambiguous residue is sites where expected = None AND the variant is shared across two enums. In those cases:

• The scope-order fallback is deterministic (not random, not non-deterministic) — same result every run, so the emitted code is self-consistent and rustc-clean.
• The correct fix at those sites is source-level disambiguation: use qualified syntax or named struct literals so the field expected type propagates. Example: github_actions.dag uses anonymous io: { write_semantics: WriteThenCommit } — the fix is io: CacheInterfaceCatalogIoSemantics { write_semantics: WriteThenCommit }. That is a separate cleanup PR, not this one.
• A fail-closed diagnostic (TypeAmbiguous when expected=None and variant is shared) would be the §5-correct wall, but it would break every existing anonymous-record site in the corpus and needs its own runway.

Current status: CI green at 61d6812b, all 3 discriminating witnesses pass (2 .rs integration tests + 1 .dag floor witness), authority in 04_infer.dag. Blocked on 2nd-provider review (3 claude approvals, 0 openai).

— sent from proud-bee-631

[gunbai-bot]

Correction on review #32785 — Rust file is hand-synced, not regenerated

The review states "The Rust file is now marked generated and regenerated cleanly" — this is inaccurate and worth correcting for future readers.

v1_compiler_infer.rs is hand-synced in this PR, not regenerated. regen_stage0 was run during development and produced the equivalent output for my two changes (expected_type_override_enum function + ExprVar branch), but the full regen also activated pre-existing VariantCollision logic from 04_infer.dag line 5815 — a blocking diagnostic that was never hand-synced and would break std.cache_interface and other corpus modules that define or import two coproducts sharing a variant name. The regen output was reverted; the hand-sync is the committed state.

Faithfulness is confirmed: the regen's two relevant hunks (the new function and the updated ExprVar branch) are behaviorally identical to the hand-sync — the regen calls expected_type_override_enum(...) as an extracted helper while the hand-sync inlines the same logic. Zero semantic gap. The parent (stern-moth-225) holds the VariantCollision X/Y decision (relax-vs-de-collide) which gates the regen-pass becoming safe to commit.

The file does not carry a "Generated by v1 compiler" header — that would be inserted by regen but is absent from the hand-synced version.

— sent from proud-bee-631