Skip to content

Emitted-Rust repair: delete the hardcoded Box in rust_host_string_op_fn_emit's string_head arm (string_tail is the control) - #9034

Merged
briansrls merged 3 commits into
mainfrom
session/smart-cat-789
Aug 24, 2026
Merged

briansrls merged 3 commits into
mainfrom
session/smart-cat-789

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Aug 23, 2026 •

Copy link
Copy Markdown
Contributor

Summary

  • remove the hardcoded Box::new from v1.compiler.emit_rust rust_host_string_op_fn_emit’s string_head arm
  • keep the string_tail arm unchanged as the sibling control
  • update the generated stage0 mirror in lockstep

Pre-registered paired-board claim

  • string_head Box-wrap E0308: 1 → 0
  • string_tail emission: UNCHANGED (map(|c| c as i64))
  • adjacent text-module identities: FIXED

Refutation condition: if string_tail emission moves, or any adjacent text-module identity moves, the claim is refuted. Two arms agreeing because the treatment/revert did not land is also a failed measurement, not evidence.

Paired-board receipt

One remote dispatch measured both arms at composite subject 8119fbd82892a84e1a2d8607cbc69788b9bb019f, with the unrelated argv repair (consolidated on #9031) and trailing-annotation repair from #9027 applied identically to both arms. The before arm was produced by inline edit, not a git ref, and both gunbc and cssl_assemble plus their tree stamps were removed between arms to force the compiler treatment to rebuild.

Setup controls printed before measurement:

  • after bare-i64 treatment present in authority/mirror: 1:1
  • before Box::new(c as i64) revert present in authority/mirror: 1:1
  • string_tail control in after/before: 1:3 / 1:3

Required regeneration before the after arm reported first_generation_equal=true, planned=133, executed=133.

Observed board:

Before After Delta
emitted files 177 177 0
diagnostics 503 503 0
cargo error total 319 318 -1
E0308 blocks 123 122 -1

Every other histogram bucket was identical. Thus the pre-registered single string_head Box-wrap E0308 vanished; it did not convert to another error code, no extra row moved, the string_tail emission stayed fixed, and adjacent emitted identities/file population stayed fixed. This receipt claims only the within-pair delta, never a comparison to the retained 316-coded-row board because the composite subject differs.

Rung

This repairs one instance at one producer edge; it is not a guarantee climb. Nothing prevents another emitter arm from hardcoding an incorrect box independently. The next-rung trigger—the authority from which per-position boxing should be derived instead of authored—is currently unknown; this PR does not invent or widen that mechanism.

Validation

  • cargo check -p v1-compiler
  • required regeneration: first_generation_equal=true
  • paired 03_ingest board: E0308 123 → 122, all other buckets unchanged

CI standing

The current required-floor failure is inherited from main: gunbc.runner_slot_provision still constructs the pre-seal ArgvCommand { argv: ... } shape. The repair is consolidated on #9031; it is unrelated to this emitter change. Regen and cited-symbol checks are green on this head.

@gunbai-bot
gunbai-bot Bot marked this pull request as ready for review August 23, 2026 16:46
@gunbai-bot

gunbai-bot Bot commented Aug 23, 2026

Copy link
Copy Markdown
Contributor Author

Recording an independent derivation of the repair rather than re-reading the receipt — because a hardcoded emitter string is exactly the kind of change where "the error went away" and "the emitted type is now right" can come apart.

The Box was wrong by the emitter's own box authority, not merely by rustc's complaint. src/v1/05_emit_rust.dag needs_box_wrapping decides Box-wrapping for a field, and for CharResult.CharFound.value every branch of it says no:

  • src/v2/std/text.dag declares CharResult = CharFound { value: Char } | CharAbsent, so the field's type node is Char — a leaf, children |> count == 0.
  • On the leaf branch, coerce_primitive_type(target: Rust, dag_name: "Char", ...) returns a name that differs from Char (it lowers to i64), so the branch returns false outright.
  • Char is in neither recursive_types nor shared_types, and the cardinality is required rather than optional, so no other branch is reachable.

So the generated enum declares value: i64, and the hardcoded Box::new(c as i64) was constructing Box<i64> into it. That is a genuine type error in the emitted program, not a stylistic mismatch, and it was one the day the string was written.

string_tail is the right control and a stronger one than the title suggests. Its arm wraps with Rc::new(...) — correct there, because ListTailResult<T> = TailFound { tail: FreeMonoid<T> } (src/v2/std/algebra.dag) declares a FreeMonoid field, which emits behind Rc. The two sibling arms carry different wrappers because their declared field types differ, which is exactly what shows the Box in string_head was not a convention being followed but a one-site mistake. A control that merely "also works" would not establish that; this one does.

One residual I checked and could not close from this repo state, flagged rather than left implicit: the emitted CharResult enum itself is not present under src/v1/stage0 — only the emitter string that produces its constructor call — so I verified the declared field type from the model and from needs_box_wrapping, not from a committed mirror showing value: i64 beside the fixed call. The execution receipt covers that join; this derivation is independent of it, which is why both are worth having.

Note this cannot get a real CI verdict until #9031 lands: the floor currently refuses at compile on the argv seal break before executing a single witness, so failed=1 on this branch is not about this change.

@briansrls
briansrls merged commit 9bbe86e into main Aug 24, 2026
2 checks passed
@briansrls
briansrls deleted the session/smart-cat-789 branch August 24, 2026 00:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant