fix(rust): map a tuple element by element - #3346
Merged
Merged
Conversation
gHashTag
enabled auto-merge (squash)
September 6, 2026 02:37
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-06 03:17:46 UTC
Summary
Seal Status
|
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
1 participant
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 #3345
The Rust type mapper had no arm for a tuple.
(A, B)fell through to the default and was emitted as written, so an inner[]f32— which every other position maps toVec<f32>— reached rustc as[]f32. The rule existed and did not travel into this position.Measured: 3 specs emit
-> (...[]...)with the old binary, 0 with the new one. The class is closed.+0 on the column, stated plainly. All three still fail, on other defects. Two of the three changed their failure cause, which is how the fix was confirmed rather than assumed. Zero regressions: 336 / 245 / 69 before and after.
My first count of the class was 6 and it was wrong. The matcher
\(\s*\[\]also caughtstd.StringHashMap([]Const u8)andstd.HashMap(T, []T)— Zig standard-library types leaking into the Rust output, not tuples at all. That is a separate and larger class: 8 specs, recorded for the next pass.The split is depth-aware: a naive
split(",")would cut(Map<K, V>, T)intoMap<KandV>and produce something worse than the input. Controls:([]f32, []u8)maps both elements, and the one-element(u32)stays(u32)rather than becoming the one-tuple(u32,), which is a different type.Found by censusing the first rustc error of all 245 failures together with the generated line — that pairing is what separated four distinct classes hiding inside one error text.