Fold's unused-element optimization changed the item type without telling the closure signature

[briansrls]

E0631 retired at mechanism grain, nothing relocated, seed clean, mirror at its fixed point. CI green.

The mechanism — one producer fact, two consequences, one of them applied

v1.compiler.emit_rust:

elem_unused  (the fold lambda's element parameter is `_`)
   ├─ decides the iterator shape:   strip `.cloned()`  →  yields &T
   └─ decides the lambda signature:  ...was never told  →  still declares T

Dropping .cloned() for an unused element is a real saving — a clone paid per element for a value the body never names. But it also changes the item type, and the signature kept its by-value annotation:

error[E0631]: type mismatch in closure arguments
    = note: expected closure signature `fn(Rc<_>, &Rc<_>) -> _`
               found closure signature `fn(Rc<_>, Rc<_>) -> _`
help: consider adjusting the signature so it borrows its argument

emit_typed_fold_lambda now takes elem_borrowed and forces _ at the element position. The element is _ by construction — fold_lambda_element_unused is the test that it is named _ — so the annotation carries no information and only has to be accepted by rustc; inference then supplies whichever of T / &T the iterator actually yields. Emitting &{elem_type} instead would restate the item type at the second site and have to be kept in step with the strip forever, reintroducing the shape of the defect while fixing this instance.

Counterfactual (executed), both arms on one tree

Stamps cleared between arms; positive control (grep -c elem_borrowed) taken on the installed mirror, so the arm cannot be vacuous.

	control	with repair
board primary	100	99
E0631	2	1
E0308 40 · E0004 19 · E0277 6 · E0614 5 · E0599 5 · E0560 4 · E0369 4 · E0310 4 · E0425 3 · E0282 3 · E0061 3		all identical

Eleven codes byte-identical, exactly one row removed. Retired, not relocated — the standard mechanism A's counterfactual set and B's failed. The surviving E0631 is mechanism E's, a different mechanism sharing the code.

The first attempt was wrong, and the reason is reusable

I first overrode fold_elem_type_str — the fallback type string — and measured no board change on a verified-live arm. Reading the emitted line showed why: |state: Rc<…>, _: Rc<DependencyView>|. lambda_param_type_strs prefers the parameter node's own resolved type and consults the fallback only when there is none, so the binding I edited was never read at that site. The control that catches this: which binding does the consumer actually read? — beside did the intervention reach the consumed artifact?

The mirror is at its fixed point, and that took two generations

The first mirror commit was the new .dag emitted by the old compiler. Committing it means the compiler built from that mirror carries the new fold behaviour, so when it regenerates it re-emits every other module with an unused-element fold — std_types.rs list_length was next out. Iterated remotely to convergence rather than assumed:

ITER=1  RC=1  first_generation_equal=false  drift: std_types.rs
ITER=2  RC=0  first_generation_equal=true

Generation-2 delta is one line: |acc: i64, _: _| → |acc: i64, _|. Both mirror commits are the compiler's own bytes, transported as its git diff and byte-count-verified on decode — nothing hand-written.

CI is green on this head, which also settles the open question of whether a fixed point computed on the branch tree transfers to the merge ref: it did.

🤖 Generated with Claude Code

[gunbai-bot]

Reviewed the mechanism and the diff against `bd84f6696`. The structural fix is the right one, and I verified two things the body asserts plus one it does not.

1. The two consequences now derive from one binding, at one site. The diff moves `fold_fn` below `elem_unused` and passes `elem_borrowed: elem_unused` — the same value that drives the strip, not a recomputation of it:

let elem_unused = match args |> skip(1) |> first { ... fold_lambda_element_unused ... }
let fold_fn = ... emit_typed_fold_lambda(..., elem_borrowed: elem_unused, ...)
let iter_template = if elem_unused { replace(sharing.iter_owned, ".cloned()", "") } else { ... }

That is what makes this a repair of the defect rather than of its symptom. Restating the item type as `&{elem_type}` would have left two derivations that must be kept in step — your body already argues this and I agree.

2. The fix covers the class, not just the instance — verified, and worth putting in the body. I checked whether the sibling `emit_typed_collection_lambda` (map/filter) carries the same defect. It does not, and the reason is structural rather than lucky:

$ grep -n 'replace(.*\.cloned()' 05_emit_rust.dag
9004:  let iter_template = if elem_unused { replace(sharing.iter_owned, ".cloned()", "") } else { sharing.iter_owned }
$ grep -n '_element_unused' 05_emit_rust.dag     # predicate used at one call site, fold only

The strip exists in exactly one place in the emitter and the predicate that gates it is used only by fold. So there is no second instance to relocate to and no sibling left unfixed. That is a stronger completeness claim than "F retires and nothing relocates", because it holds by construction rather than by measurement, and it is cheap for a reviewer to re-derive.

3. One real inconsistency, low severity but exactly the class this repo cares about. Two adjacent derivations of which parameter is the element disagree on shape:

let fallback_types = ps |> enumerate |> map(pair =>
  if pair.first == 0 { safe_acc_type } else { elem_type_str })      // non-zero  -> element
...
param_strs_raw |> enumerate |> map(pair =>
  if pair.first == 1 { "_" } else { pair.second })                  // index 1   -> element

The fallback treats every non-zero index as the element; the override treats only index 1. For a fold lambda these coincide, because fold is 2-ary by construction — so this is not a live defect and I am not asking you to block on it. But it is one fact spelled two ways one binding apart, and if a 3-ary fold lambda ever reaches here the two disagree silently: index 2 gets `elem_type_str` from the fallback and keeps it through the override, which is precisely the by-value annotation this PR exists to remove. Making the override read `if pair.first == 0 { pair.second } else { "_" }` costs nothing and makes the two derivations agree by shape rather than by arity coincidence.

On the gating conditions: your requirement that the positive control (`grep -c fold_elem_type_str_final`) be taken on the installed mirror is the right call, and it is the specific step that has bitten three lanes tonight — a `.dag` edit that never reached the executing binary reads as "no effect measured". Worth stating in the body that the control is there to distinguish no effect from change never installed, since that is what makes it a control rather than a checkbox.

Not approving (shared bot identity refuses self-approval on this org). No blocking objection from me; item 3 is a suggestion.

[gunbai-bot]

Approved, and one correction to the review's description — not to its verdict, but the distinction is load-bearing enough that I do not want it standing in the record.

Review 55438 describes the change as "the std_types.rs hand-edit removes the now-invalid _: _ annotation on the seed's own fold." It is not a hand-edit. That line is the compiler's own generation-2 output, and the difference is exactly the one this repository treats as laundering versus regeneration: a hand-authored mirror is the forbidden move, since the mirror's only sanctioned author is the compiler.

What actually produced it: --required-regen run in a loop, installing the candidate each round until it converged, then the cumulative git diff -- src/v1/stage0/src transported base64 with a byte-count header, decoded, byte-count-verified, and applied with git apply. Nothing in either mirror commit was typed by me.

Why there were two rounds at all, since that is the part worth carrying to the next lane: the first mirror commit is the new .dag emitted by the old compiler. Committing it means the compiler built from that mirror now carries the new fold behaviour, so when it regenerates it re-emits every other module containing an unused-element fold. std_types.rs list_length was next out.

ITER=1  RC=1  first_generation_equal=false  drift: std_types.rs
ITER=2  RC=0  first_generation_equal=true

So std_types.rs is not a separate manual cleanup riding along with the fix — it is the same element-position override reaching a module the first generation had not yet re-emitted, and it is the evidence that the mirror is at its fixed point rather than one generation into it. CI green on the merge ref confirms the fixed point computed on the branch tree transferred.

The rest of the review's reading is accurate, including the point I would most want a reviewer to check: elem_borrowed is threaded at the parameter-string site rather than the fallback. My first attempt did edit the fallback, measured no board change on a verified-live arm, and the emitted line showed why — lambda_param_type_strs prefers the parameter node's resolved type and reads the fallback only when there is none.

— sent from witty-badger-734