fix(rust): a field named type is a keyword, and the name has four positions (+1) - #3242
Merged
Merged
Conversation
compiler.rs:8322 maps "str" | "string" to []const u8 for Zig and
compiler.rs:18248 maps it to const char* for C. compiler.rs:24426 mapped it to
the owned String for Rust, and String is not constructible in a `const` item,
which is where the corpus mostly uses it:
pub const DEFAULT_NOTEBOOK: String = "t27-QUEEN-BRAIN";
error[E0308]: expected `String`, found `&str`
48 of the 75 specs whose first error was E0308 carried that mismatch.
Measured by name over all 650 corpus specs: rustc accepts 288 -> 314, +26, zero
regressions.
The judgement is stated rather than hidden. `&'static str` is narrower than
String -- a field of that type holds only a string living for the program -- and
that narrowing is what both siblings already chose, neither []const u8 nor
const char* owning its bytes. Zero regressions says nothing in the corpus needed
the owned form.
Also records the boundary my predictor from #3219 was missing. That rule ties a
fix's yield to the stub-bodied share of its class; this class is 3% stub-bodied
and I predicted +2..+8 against a measured +26. The rule holds for a fix repairing
a SIGNATURE while leaving a body, and not for one repairing a COMPLETE
DECLARATION: a const is correct or not on its own.
Seal and 92 drifted seals move in the same commit.
Closes #3239
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ositions (+1) A spec field may be named `type`, `ref` or `match`. Those are Rust keywords and the emitter wrote them bare, so the struct did not parse. `r#type` is the exact spelling and needs no judgement. The name is written in four places -- the field declaration, a field access, a function parameter and a struct literal -- and repairing the first two changed nothing beyond one spec. Repairing all four changed nothing further: the remaining specs of the class carry other defects behind the keyword. Measured by name over 650 specs: 314 -> 315, +1, zero regressions. The honest measure here is closure, not yield: `found keyword `type`` as a first error goes 7 -> 1, and the residue is a different cause (keywords in TYPE position, from #3225's list-valued declaration). crate/self/Self/super are deliberately not escaped: `r#` is invalid for them, so escaping would swap one parse error for another. Also records a measurement flaw that has misled me three times: taking the LAST numbered line of rustc's first error block reads back the SUGGESTION, since suggestions render as numbered lines and come last. It produced a phantom `pub struct ListNode<T>` earlier and made two specs here look already-repaired. Closes #3241 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
enabled auto-merge (squash)
September 5, 2026 03:22
This was referenced Sep 5, 2026
Merged
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
This was referenced Sep 5, 2026
Closed
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-05 04:18:24 UTC
Summary
Seal Status
|
This was referenced Sep 5, 2026
…names # Conflicts: # .trinity/seals/File.json # .trinity/seals/Git.json # .trinity/seals/GitDiff.json # .trinity/seals/GitOperations.json # .trinity/seals/Hir.json # .trinity/seals/VcdConformanceCompare.json # .trinity/seals/file_File.json # .trinity/seals/fpga_Hir.json # .trinity/seals/fpga_VcdConformanceCompare.json # .trinity/seals/git_Git.json # .trinity/seals/git_GitDiff.json # .trinity/seals/git_GitOperations.json # .trinity/seals/race_igla-race-formal.json # bootstrap/stage0/FROZEN_HASH
…ust-keyword-field-names
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-05 06:34:03 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.
A spec field may be named
type,reformatch. Those are Rust keywords and theemitter wrote them bare, so the struct did not parse. Rust's raw-identifier syntax
r#typeis the exact spelling and needs no judgement.Four positions, and the first two were not enough
The name is written in four places and repairing two of them changed nothing beyond
the first spec:
pub type: T,x.typepub fn f(type: T)Event { type: v }Measured: 314 → 315, +1, 0 regressions — the same +1 after two positions and after
all four, because the remaining specs of the class carry further defects behind the
keyword.
The class is closed, which is the honest measure here
found keyword \type`as a **first** error: **7 → 1** across the corpus. The residue under "found keyword" is a different cause —enum(5),struct(2),mod` (1) — thoseare keywords in type position, from the list-valued declaration of #3225, not field
names.
crate,self,Selfandsuperare deliberately not escaped:r#is invalidfor them, so escaping would swap one parse error for another. None occurs as a field
name here, and if one appears it stays bare and fails visibly.
A measurement flaw that has now misled me three times
To find the failing source line I was taking the last numbered line of rustc's
first error block. rustc renders its suggestion as a numbered line, and suggestions
come last — so I read back the corrected code as if it were the defect:
It produced a phantom
pub struct ListNode<T>earlier, and here it made two specs lookalready-repaired. The correct extraction is the first numbered line after
-->.Closes #3241