refactor(types): bring TY3 impl in line with the synthesis-only lock #17
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/017-refactor-types-bring-ty3-impl-in-line-with-the"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
refactor(types): bring TY3 impl in line with the synthesis-only lock
Along the way:
Touches 38 files:
docs/impl/01-front-end.md,docs/impl/04-name-resolution.md,docs/impl/08-diagnostics.md,docs/impl/README.md,docs/impl/resolution/README.md,docs/impl/slices.mdand 32 more.It runs per token. The buffer behind
expand_data_typelives on the struct insrc/rust/crates/ck_types/src/value_turbofish.rsnow and is cleared rather than reallocated.Nothing outside calls
payload_arity. It is pub(crate) insrc/rust/crates/ck_syntax/src/data_variants.rsnow.Reads well. One question on
src/rust/crates/ck_types/src/value_turbofish.rs, nothing blocking.@ -0,0 +62,4 @@/// (`Maybe::None`) when this is 0; a payload-bearing variant is a/// generic record in TY6.#[must_use]pub fn payload_arity(self) -> usize {payload_arityis public. Does anything outside the crate call it, or is it pub because that was easier? Every public item is a promise.@ -0,0 +76,4 @@.into_iter().map(|tref| lift_required_type_ref(tref, src, scope, interner, caller_generics)).collect();expand_data_type(parent, &pinned, interner).unwrap_or_else(|| Ty::nominal(vid, Vec::new()))expand_data_typeallocates a fresh buffer per call. If this runs per frame or per token, can the buffer be reused?Delta A of the coordinated landing. The synthesis-only inference lock (2026-05-28, docs/impl/type-system/inference.md) closes the door on pulling a type inward from the surrounding context. The TY3 v0 impl shipped with an ExpectedReturn binding source and an Option<&Ty> threaded through the walker; both are now removed. Walker (ck_types/src/check.rs): - synth_with_expected dropped; synth is the one entry point. - The Option<&Ty> parameter is gone from synth_uncached, synth_call, synth_generic_call, synth_block. Every expression synthesizes from its own text; the boundary (check / argument-vs-parameter) asserts the assignability relation against the synth. - check() no longer special-cases bare Int literals against fixed-width expected pins. Per the lock, a bare numeric literal *always* synthesizes its default (Int / F64); the only path to a fixed-width value is a turbofish at the literal site. (TY2's locked open item.) - collect_arg_bindings uses synth, not synth_with_expected. - synth_block's tail synths plain; no expected threaded to the trailing expression for "tail call pinning from declared return." - CallSite.expected_span field removed (it only fed the ExpectedReturn secondary). Instantiation (ck_types/src/instantiate.rs): - BindingOrigin::ExpectedReturn variant removed; the binding map now carries Argument origins only (Turbofish lands in Delta C). - Module doc rewritten: two sources, in order — turbofish then arguments. The expected-return entry is gone; an explicit paragraph cites the synthesis-only lock and the redirect "turbofish at the call site" remediation. Diagnostics (ck_types/src/diag.rs): - source_phrase / source_label drop the ExpectedReturn arm. E0706's doc comment retargets at "(turbofish or arguments)". Tests: 720 passed. Clippy: 0 warnings. Doc-link checker: 0 missing anchors. No fixture surgery needed: conflicting_bindings.cktest's expected diagnostic already names the two argument sources ("Int from argument 1, String from argument 2"); the post-substitution E0702 cascade still fires.