fix(rust): int, uint, float and double, which every neighbour already answers - #3334
Merged
Conversation
gHashTag
enabled auto-merge (squash)
September 5, 2026 19:32
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #3323
t27_array_type_to_zig(compiler.rs:8349) carries"float" => "f64","double" => "f64","int" => "i32","uint" => "u32"with a comment naming the same defect one backend over:The C emitter matches
"f16" | "f32" | "f64" | "float" | "double"in three places. The Rust mapper knew none of them.The column does not move. Two pinned binaries of distinct hashes, 651 specs: 336 OK both sides, zero regressions.
What moves is the emission, and that is the claim being made here. 5 specs change their generated Rust —
pub step_id: int→pub step_id: i32,Vec<int>→Vec<i32>— andcannot find typeint/float`` was the FIRST rustc error on 3 of them and is now the first error on none. Their new first errors areK_TRUEand `Trit`, which is how the fix is known to have landed rather than assumed.Deliberately narrow: capitalised
IntandFloatare not mapped. No neighbour answers those, so mapping them would be a decision rather than a transfer.Method note. The first measurement was discarded: I rebuilt the compiler while the baseline run was still going — the ruler moved under the measurement — so both sides were re-run against binaries pinned before either started.