[Yumihariii]

Fixes #3585 — the named-slice-alias residual family of the copy() element-width soundness gap. Following the DUP CHECK on #2940: the four anonymous shapes in that table are genuinely closed by landed #3145 and this PR does not re-litigate them (#2940 will be closed as superseded). What remains, verified empirically against d6507a52e, is that the check never resolves element spellings through the alias registry, so named slice aliases behave differently from their anonymous spellings.

The delta

copy_slice_elem_scalar in buildable.rs — one resolution step inserted ahead of the existing comparison logic:

• (slice, slice) arm: element spelling comes from the binding text as today; when the variable's declared type is a named slice alias (type my_int64_slice = []int64), it now resolves through named_slice_element_name (hy-check accepts invalid slice-to-string and string-to-slice conversions (non-byte/rune elements) violating Row 13 BUILDABLE #2811's registry resolver, same precedent that fixed the sibling gap there) before canonical_numeric_name. copy(named_int64_slice, named_int32_slice) / copy(named_float64_slice, []float32{…}) now reject with the real widths in the label instead of being accepted with 0 diagnostics and dying in go build.
• (slice, string) arm: the byte-destination check goes through the same resolution, so type bs = []byte; copy(bs_dst, "hi") — legal in Go — is no longer rejected with the misleading element type int`` fallback label.
• Canonical spellings stay silent (byte=uint8, rune=int32 — pinned by copy_named_rune_slice_from_int32_slice_accepted); unresolved elements, user-defined element types and aliases-of-aliases fail open, matching the hy-check accepts invalid slice-to-string and string-to-slice conversions (non-byte/rune elements) violating Row 13 BUILDABLE #2811/hy-check: slice and map literals permit mismatched concrete numeric types (Row 13 BUILDABLE) #2788/Soundness: hy-check accepts append with mismatched concrete numeric types (Row 13 BUILDABLE violation) #2796 convention. No anonymous behavior changes: the binding-text path is untouched when it resolves.

Evidence (this tree)

• RED on stock main (d6507a52e): 3/6 of the new suite fail — both false negatives accept with diagnostics: [], the false positive rejects with the `int` fallback label (exact outputs in hy-check: copy() misses named slice aliases — width mismatches accepted (FN) and legal []byte-alias string copy rejected (FP) #3585).
• GREEN here: new suite copy_slice_named_alias_3585.rs 6/6; upstream issue_3085_copy_slice_soundness 16/16; issue_2655_copy_slice_elem_soundness and hy-check --lib unchanged pass.
• Full crate: cargo test -p hy-check → 288 suites, 2158 tests, 0 failed. cargo check --workspace --all-targets clean. (Env: rust toolchain pinned to 1.99.0 per tools/env.sh.)

Scope check: one checker function + arm rewiring in buildable.rs (+58/−23), one new test file, nothing else touched.

[Yumihariii]

Rebased onto main tip (86aabf0), new head 32c7bff7 replaces f0972e04; patch-id 9c538404… byte-equal across the rebase — same narrow scope as opened (named slice/alias element resolution in the two copy element checks, nothing else).

Full hy-check suite on the new base: 297 suites, 2179 passed, 0 failed (dedicated target dir, rust 1.99.0 / go1.26.9 pinned). RED/GREEN from the issue repro still holds: the three alias shapes reject after the fix, fail-open surface unchanged.

[Yumihariii]

Rebased onto current main (0a40291), clean apply, still ahead=1 with an identical patch-id — diff unchanged (buildable.rs copy-element alias resolution + tests/copy_slice_named_alias_3585.rs).

Re-run on the new base, full cargo test -p hy-check: 2193 passed / 0 failed. Targeted: our 6/6, upstream issue_3085 suite 16/16, issue_2655 neighborhood 6/6. fmt drift on hy-check is 984 diffs on plain main and 984 on this branch — this commit adds none.

This is still the only open PR that fixes the named-alias residual (#3585): copy([]NamedInt64, []NamedInt32)-style assignments with declared slice aliases pass check on bare main and die at go build, per the repro measurements posted in #3585.

[Yumihariii]

Rebased onto 5a2990c — main gained ten commits since the base of the previous head (sessions 101/102), taking us past the behind-15 line we work to. Replay was conflict-free even though 101/102 landed copy/length-adjacent checks (#3701, #3703); patch-id identical to the old head (9c538404…), so nothing about the fix changed.

Evidence on the rebased tree:

• cargo test -p hy-check against a dedicated target dir: 309 suites, 2203 passed, 0 failed.
• Targeted copy_slice_named_alias_3585: 6/6 (the named-alias shapes fix(hy-check): reject element scalar mismatches and non-byte string copy in copy() (fixes #3085) #3145 doesn't cover).
• Upstream neighbors intact: issue_3085_copy_slice_soundness 16/16, issue_2655 6/6, copy_clear_soundness 10/10.
• fmt drift parity with plain main (993 == 993 — no new drift introduced).

Saw the board put this PR in land-candidates after the 21:29 sync — thanks for keeping it on the radar; behind is 0 again and CI is already running on the new head.

[Yumihariii]

Head refreshed onto ce01933 (fb21598cdd), replayed cleanly, patch-id byte-identical to the r148 head (9c538404…) — the named-alias fix itself is unchanged. Worth noting the new base includes session-104's #2934 (builtin len/cap/copy/min/max range bounds) and #3612 (array literal lengths in typed_value_type_name), both adjacent to where this PR edits — the merge is conflict-free and the combined behavior holds: full cargo test -p hy-check on the merged tree 315 suites / 2245 tests / 0 failures, including our targeted copy_slice_named_alias_3585 6/6, upstream issue_3085 16/16 and issue_2655 6/6, plus cargo fmt --check clean (0 diffs, same as plain main).

[Yumihariii]

Rebased onto c3c78c0 (main) — new head 98715e5dcc, patch-id unchanged from fb21598cdd (9c538404…). The replay landed cleanly on top of #3438's buildable.rs changes: no conflict, both fixes coexist as-is. Evidence on the merged version: my named-alias suite copy_slice_named_alias_3585 6/6 pass, the three suites that just landed (elided slices in map/any slots, shadowed type args, map-key comparability) all pass unchanged, and hy-check --lib is 180/180. So the #3585 gap is still live on current main and my fix adds to #3437/#3438 rather than duplicating them.

[Yumihariii]

Rebased onto current main (b8069b3) — 20 behind after the session-108/109 land wave, past our update line. Clean single-commit replay, patch-id 9c538404963c67e44ca446ef635819212199cbda byte-identical to the previous head.

Checked whether the wave touched our gap (buildable.rs got +371 lines from #3694/#3718): ran our test file against bare main without the fix → 3 of 6 still fail (copy_named_int64_slice_from_named_int32_slice_rejects, copy_named_slice_from_literal_other_width_rejects, copy_named_byte_slice_from_string_accepted). So the named-slice-alias shapes of the copy() family remain uncovered by the landed composite-bounds/sized-array fixes — this PR is not superseded.

Gates on the merged version (main + our commit), all green:

• our suite: 6/6
• upstream suites landed in the wave: buildable_composite_array_bounds_3694 1/1, index_store_share_3707 8/8, issue_1599_fn_signature_comparison 2/2, issue_generic_type_param_builtins 2/2, issue_sized_array_return_map_parallel 2/2, tuple_composite_fn_callee_arity_3722 2/2, multi_value_tuple 12/12
• cargo test -p hy-check --lib → 181/181

New head: 9c740f46bbde0c1f3070d4d1af5c5c723eac9faf (ls-remote verified). bot:stale-base label is sticky from the frozen board snapshot; behind is 0 against b8069b3 now.

[Yumihariii]

Rebased onto current main deae2fc (session-110 tip) after the 16-commit drift; head is now 2f1e0be.

• Patch replays byte-for-byte: git patch-id --stable = 9c538404963c67e44ca446ef635819212199cbda, identical to the previous head 9c740f4. Fix content untouched.
• Re-ran the DUP probe against this wave because hy-check: resolve [N]T, map[K]V, and option[T] in generic struct field kinds (fixes #3705) #3706 landed +71 lines into buildable.rs: on bare deae2fc with only the new test file, the suite fails 3/6 with exactly the hy-check: copy() misses named slice aliases — width mismatches accepted (FN) and legal []byte-alias string copy rejected (FP) #3585 shapes (copy(int64_slice_alias, int32_slice_alias) and the literal-width FN accepted with 0 diagnostics; copy(namedByteSlice, "s") rejected as element int). Session-110's landings extended struct-field / generic-kind / map-key resolution, not the copy() named-alias arms — the gap in hy-check: copy() misses named slice aliases — width mismatches accepted (FN) and legal []byte-alias string copy rejected (FP) #3585 is still live.
• Merged-tree gate (fresh rebuild, all green): our suite 6/6, this wave's upstream suites buildable_generic_struct_composite_fields_3705 1/1, const_zero_divisor_len_and_neg_shadow_3708 3/3, recv_composite_field_channel_operands_3716 2/2, plus the neighbors we must not regress: issue_3085_copy_slice_soundness 16/16, issue_2655_copy_slice_elem_soundness 6/6, hy-check --lib 181/181.
• hy-check: copy() misses named slice aliases — width mismatches accepted (FN) and legal []byte-alias string copy rejected (FP) #3585 remains open and fix(hy-check): resolve named slice aliases in copy() element width check (fixes #3585) #3597 is the raw +3/-0 variant without tests; this PR carries the checker fix plus the 6-case negative/positive suite.

Happy to answer review questions; checks on the new head should appear shortly.

[Yumihariii]

Rebased onto current main (c716aeb) to keep this in sync with the session-112 landings — zero conflicts, patch-id 2f1e0be→9408f67 (my commit content conserved) unchanged, so the fix content is byte-identical to what you already saw. behind is back to 0.. Re-validated post-rebase with a forced recompile against the new base: cargo test -p hy-check fully green (lib 183/183 plus every integration suite, zero failures), including the six regression tests in copy_slice_named_alias_3585 (3 accept-path + 3 reject-path). New head: 9408f67. CI on the new head should follow the usual quick/compiler path; nothing here needs re-review, it is purely a freshness rebase. Thanks for the two lands today (#3673/#3675) — checked the wave before rebasing: it touches hy-check freeze/shape and hy-emit lib/stmt only, no overlap with this PR's files.

[Yumihariii]

Rebased onto current main (8b8f5fa, 16 behind → 0), same content: patch-id 9c538404963c67e44ca446ef635819212199cbda is byte-identical to the previous head, so nothing in the fix moved.

Since the two landed PRs this session touched buildable.rs too, I re-checked DUP status against bare main@8b8f5fa with only my test file mounted: 3 pass / 3 fail — the failures are exactly the named-slice alias cases (copy([]NamedInt64, []NamedInt32) width pair, named-slice-vs-literal other width, and the named []byte-from-string accept arm), i.e. the gap in this PR is still real and untouched by #3727/#3730.

Merge-tree gate on the new head: targeted copy_slice_named_alias_3585 6/6, upstream shadowed_lowering_os_filepath_soundness 15/15, tuple_ptr_arr_bounds_and_method_fn_3729 2/2, and the full hy-check crate re-run shows 334 test binaries with zero failures. Fresh head ca5fd36, checks re-queued.

[Yumihariii]

Refreshed the branch after sessions 118-119 landed: rebased onto current main (2a6ebf9, 23 behind → 0). Content is unchanged — patch-id of the replayed commit is identical to the old head (9c538404… both sides).

Re-ran the tests on the new head: copy_slice_named_alias_3585 6/6 pass, cargo test -p hy-check --lib 183/183 pass. The landed checks this morning (arith / const_init / elided_literal / try_context) don't touch buildable.rs, so this stays a clean replay.

One heads-up: bot:stale-base on this PR is pinned from board v43 — the triage-board workflow has failed five runs in a row (last success Nov 1), so no v44 has been published to correct it. The actual behind count is 0.

[Yumihariii]

Branch updated to current main: rebased 63b327d -> 982e8d9 onto f9c4997 (23 behind -> 0). Pure replay, patch-id 9c538404... identical on old and new head — the #3759/#3761/#3763 waves land in const_overflow/resolve/walk, disjoint from my buildable.rs hunk and test file.

Verification on the merged tree: copy_slice_named_alias_3585 6/6 pass, hy-check lib 183/183 pass.

FYI the bot:land-candidate+bot:stale-base labels are stale board v43 artifacts (board job still failing since 11-01); the branch itself is now at zero behind.

[Yumihariii]

Updated the branch onto fca2f63. Note both newly landed PRs (#3771, #3772) touch the same crate and buildable.rs-adjacent logic, so I did not just take the clean textual rebase for granted — ran everything against the merged tree in an isolated target dir:

• copy_slice_named_alias_3585: 6/6
• upstream issue_3240_delete_key_scalar_array_checks: 4/4
• upstream issue_3572_errors_wrap_operands: 4/4
• hy-check --lib: 183/183

Patch replay is byte-identical (9c538404), zero conflicts, and the named-alias gap from #3585 is still open on bare main — none of the landed rules cover those shapes.

[Yumihariii]

Rebased onto 10d28c5d after #3793 landed nearby in buildable.rs — our commit applies cleanly and is byte-identical (patch-id 9c538404963c67e44ca446ef635819212199cbda unchanged). Gate on the new head: copy_slice_named_alias_3585 6/6, upstream issue_3085_copy_slice_soundness 16/16, hy-check lib 183/183, all green. Noting it was bot:land-candidate before this push; bot:stale-base predates it and should clear on the next board pass.

[Yumihariii]

One note for the verify pass: the red quick on this head is repo-wide and content-independent — see #3945. It fires on every main push since 8b914525 (install.sh gained an mv-based backup step in #3788; the offline harness PATH in test_install_runtime.py never exposed mv), and it hit already-landed PRs (#3798) exactly the same. Fix PR #3946 is one harness line (RED 27 failures → GREEN 14/14 measured at cc2de7a7); once it lands, quick goes green here and on all fork heads again. compiler passes on this head, and the full gate evidence is in the rebase comment below.

[Yumihariii]

Rebased onto fef44be (green tip). patch-id 9c538404963c67e44ca446ef635819212199cbda identical to the previous head — clean replay of the single fix commit.

Merged-tree gate, fresh target dir to dodge cache staleness:

• own copy_slice_named_alias_3585 suite: 6/6
• the copy-slice neighbors sharing buildable.rs: issue_3085 16/16, issue_2655 6/6, copy_clear_soundness 10/10, copy_const_scope_and_closure 9/9
• hy-check lib: 183/183

Zero regressions. The prior head's quick=FAILURE was the #3945 repo-wide red bleeding in, addressed in the earlier comment; bot:land-candidate + bot:stale-base come from the frozen board — actual behind is 0 from this base.

[Yumihariii]

Rebased onto 0c1a9cd. Worth noting: session 141/142 did touch buildable.rs (+31 via the shape-provenance land), so before re-applying I placed the six-test suite alone on bare 0c1a9cd — still 3 failures, all named-slice-alias shapes (int64-from-int32 named, literal other-width, byte-slice-from-string). The gap this PR fixes survives the wave, so it is not superseded. The rebase itself merged cleanly (hunks disjoint) with byte-identical patch-id (9c538404), and the full -p hy-check suite on the merged tree is green: our copy_slice_named_alias_3585 6/6, issue_3085 16/16, the four new wave suites (builtins_closure_local_index_store, handle_share_and_closure_const, interp_shadowed_fmt_3568, tuple_forwarded_and_const_arity) all pass, 0 failures anywhere.

[Yumihariii]

Rebased onto main@0e3ed6aad8 era tip (34 behind → fresh; patch-id byte-identical vs previous head bac96f2ad8 — replay was a pure fast-move, zero conflict even though #3886 landed in buildable.rs nearby).

Since #3886 touched the same file, I re-ran the diff probe per the standing protocol: our 6-test suite dropped onto bare current main → still 3 FAILED (exactly the named-slice-alias shapes: copy_named_slice_from_literal_other_width_rejects, copy_named_int64_slice_from_named_int32_slice_rejects, copy_named_byte_slice_from_string_accepted). The landed wave does not close #3585; the gap this PR fixes is still live on main.

Merged-tree gate: full cargo test -p hy-check → 377 suites, 0 failures; targeted copy_slice_named_alias_3585 6/6, upstream issue_3085_copy_slice_soundness 16/16, issue_2655 6/6.

[Yumihariii]

Rebased onto 736d2d8, which now carries the landed #4087 printf-family validation in the same buildable area. No interaction: replay kept the patch-id byte-identical (9c538404), and cargo test -p hy-check on the merged tree passes — 381 suites, 0 failures, including both the landed fmt suites and the named-alias copy tests from this PR.

[Yumihariii]

Rebased onto current main (94b0e14) per the board's update-branch action; patch-id unchanged (byte-identical replay of the named-slice-alias fix). On the new base: copy_slice_named_alias_3585 6/6, hy-check lib 183/183, 0 failures. The #3988 attribution note applies here too — any compiler-job examples-e2e failure on current main comes from the known examples breakage (#4236), not from this diff.