The &mut/& split makes a same-array mem_copy unrepresentable in Rust, where C expresses it #4825

Re-filed from #3404. An attempt claimed that issue on 2026-09-23 and left an empty branch, and a dispatch row that has spent its retry ceiling keeps its issue for good - so no bee could take it again, however much the brief improved. The work below is carried over unchanged.

Found by adversarial review of #3403. Latent: population 0 in todays emitted Rust. Filed so it is not discovered later as a surprise.

The shape

specs/isa/ternary_memory.t27:226:

fn mem_copy(dst: []TernaryWord, dst_addr: u32, src: []TernaryWord, src_addr: u32, count: usize) -> bool

Its body carries an explicit two-branch overlap handler — "Handle overlap (copy direction matters)" — forward when dst_addr < src_addr, backward otherwise. That branch exists for exactly one situation: dst and src are the same array. And the spec exercises it that way, twice:

• line 388, test mem_block_copy_overlap → mem_copy(memory, 0, memory, 1, 2)
• line 472, invariant mem_copy_handles_overlap → mem_copy(memory, 0, memory, 1, 2)

What #3403 does to it

dst is index-assigned so the fixpoint marks it; src is not. The emitted signature becomes

pub fn mem_copy(dst: &mut [TernaryWord], dst_addr: u32, src: &[TernaryWord], src_addr: u32, count: usize) -> bool

and the spec own call is then unrepresentable in safe Rust:

error[E0502]: cannot borrow `memory` as immutable because it is also borrowed as mutable
  mem_copy(&mut memory, 0, &memory, 1, 2)

The backward-copy branch becomes dead by type. C takes two pointers and can express the call; Verilog can too. So this is a place where the four backends do not agree about what the spec means — the property the project exists to hold.

Why it is not urgent, stated precisely

• The two same-array calls are inside a test and an invariant, and gen-rust lowers neither.
• The emitted Rust contains the definition of mem_copy and zero call sites.
• E0502 count in that file: 0 on master, 0 after fix(rust-backend): a written []T parameter is &mut [T], to a fixpoint #3403. Measured, not assumed.

It becomes live the moment tests or invariants are lowered to Rust — which is a direction this project wants to go, so the cost is deferred rather than avoided.

Options, none of them free

1. Refuse the shape. When one function has both a written slice parameter and a read slice parameter of the same element type, the &mut/& split cannot express a same-array call. Leave that function parameters as they were and declare it on the existing NOT LOWERED BY THIS BACKEND header line, so the omission is disclosed rather than silent.
2. Lower it as one slice plus indices, matching what slice::copy_within does. That changes the spec surface, not just the backend.
3. Accept it and say so in the spec, marking mem_copy as a construct whose Rust lowering is weaker than its C and Verilog lowerings.

Option 1 is the one that keeps the honesty property this repository already has a mechanism for. Which of the three is the owner call.

Boundary

• specs/isa/ternary_memory.t27

The instruments

Every one of these reads and prints; none of them writes. Run them from the repository root, with <spec> replaced by the file in ## Boundary:

.t27 is not Rust and not Zig, and a bee fluent in either writes one by
accident. Measured 2026-09-20: a bee filled eight bodies in
specs/file/watcher.t27 with return Ok(());, Err(FileError::WatcherNotFound)
and for i in 0..watchers.length. The parse ratchet refused the whole file --
Unexpected token in expression: RParen, line 123 -- and a spec that does not
parse generates nothing, so every test it already carried stopped running.

At the top level the parser accepts exactly these eight forms, with an optional
pub, and no others:

const   var   fn   enum   struct   test   invariant   bench

There is no trait, no impl, no type X = ..., no generics, no macro. What
a bee reaches for from another language, and what happens:

• Rust's result sugar (Ok(()), Err(E::V), ?) is not a construct here.
• Rust macros (println!, format!, vec!) are not constructs here.
• A range loop (for i in 0..n) is Rust and Zig, not this language.
• Zig builtins (catch unreachable, @intCast, @constCast) are not constructs here.
• Cross-module reuse (use other::fn;) parses and then generates a comment and an unqualified call, so the Zig fails with use of undeclared identifier (use a::b; generates no import, so no spec can reuse a function from another spec #4298). It does not work yet.

t27c parse <spec> answers in one line whether what you wrote is the language.
Run it before you report, every time.

• t27c spec-status <spec> - the compiler's one-word verdict: IMPLEMENTED, PARTIAL, UNWRITTEN, NOPARSE, NOFN. Exit code is 0 whatever it says, so read the word.
• t27c symbols <spec> - every name the file declares, with its kind. Answers "does this already exist here?" before you add it.
• t27c outline <spec> - per function: its locals, what it calls, what it returns. The contract you are implementing against.
• t27c coverage <spec> - which functions have a test and which do not. The issue asks for tests; this is how you check you wrote them.
• t27c lint <spec> - style and shape warnings. It OVER-REPORTS has no test or invariant: measured 2026-09-20 over 60 specs it printed 677 of those where coverage found 190 untested functions, disagreeing on 59 of the 60 - it warns about bit_to_trit_pair in specs/base/ternary_encoding.t27, which test bit_to_trit_pair_zero calls on line 249. Read it as a hint; coverage is the answer.
• t27c typecheck <spec> - types, before generation. Prints Typecheck OK (0 errors, 0 warnings) or the errors.
• t27c test-report <spec> - builds this spec and runs its own tests, which is what the oracle does. BLOCKED means the generated Zig does not compile, with the error beside it.
• python3 tools/dupe_scan.py --name <function> - where that function already lives, if it does. 576 of 4021 bodies here are byte-identical copies.

The rest of the toolbelt is in docs/BEE_TOOLBELT.md.