Repository navigation
fix(rust): [T] lost its element type, and "string" was not an alias (+5, 0 regressions) - #3215
Merged
Merged
Conversation
…+5, 0 regressions) Two spellings share the shape `[...]` and put the element type on opposite sides of the bracket. Zig-style `[N]T` has the size in the brackets and the element after them; t27's own `[T]` -- the spelling the corpus uses, as in `proof_steps: [ProofStep]` -- has the element in the brackets and nothing after. `t27_type_to_rust` read only the tail, so 52 specs received `Vec<>`, which rustc cannot parse, hiding everything behind it from any first-error histogram. Adjacent: the Rust mapper knew "str" and not "string", so 34 specs using the long spelling received the bare word `string` as a Rust type. Neither fix required a judgement about meaning. The C emitter already writes `ProofStep* proof_steps;` and `const char** args;` for these fields, and the Zig mapper already spells the alias `"str" | "string"` at compiler.rs:8322. Same shape as #3208: a rule that exists in one emitter and never travelled to its sibling. Measured by name over all 650 corpus specs: rustc accepts 237 -> 242, +5, zero regressions; specs emitting a degenerate type 52 -> 22. The 22 left are the `pub f: ,` form, a different cause. Seal and 40 drifted seals move in the same commit; only gen_hash_rust and sealed_at change. Closes #3213 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
enabled auto-merge (squash)
September 5, 2026 00:20
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
Contributor
PR DashboardGenerated at: 2026-09-05 00:32:20 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
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.
Two spellings share the shape
[...]and the element type sits on opposite sides ofthe bracket.
t27_type_to_rustread only one of them.For
[N]Tthe element follows the bracket and this is right. For t27's own[T]—the spelling the corpus actually uses, as in
proof_steps: [ProofStep]— the elementis inside the bracket and
afteris the empty string. 52 specs receivedVec<>,which rustc cannot parse, so everything behind it in the file was invisible to any
first-error histogram.
A second, adjacent miss: the Rust mapper knew
"str"and not"string", so 34 specsusing the long spelling received the bare word
stringas a Rust type.The target was set by sibling backends, not inferred
[ProofStep]correctly — the same field comes out asProofStep* proof_steps;, and[string]asconst char** args;"str" | "string" => "[]const u8"atcompiler.rs:8322Both fixes are the same shape as the one in #3208: a rule that exists in one
emitter and never travelled to its sibling.
Measured, 650 corpus specs, by name
Vec<>orpub f: ,The 22 that remain are the
pub f: ,form — an empty field type, a different cause —and are not touched here.
The gap between "52 specs stopped emitting a degenerate type" and "+5 accepted" is the
same distinction #3208 recorded: a first-error count is not an unblocking count.
Closes #3213