tri misread: a bare colon in a type, and the comment that deletes the next field - #3244
Merged
Merged
Conversation
An inline `#` comment on a struct field consumes the rest of the line AND the declaration that follows. Five lines reproduce it; `parse` and `typecheck` both accept; all three backends emit one field where the spec wrote two, and the second is gone. specs/tri/pipeline/pipeline_parallel.t27 loses four declarations to one comment. Found from a seal file named `agent_"[]const u8".json`. A seal is named after a module, so a seal named after a type expression meant something upstream had read one as the other. Eleven such seals exist, each pointing at a spec that already carries a correctly-named one. The new shape is named for what the OUTPUT shows: a bare colon inside a type, which a Rust type never has since a path spells its separator `::`. I called it RustSwallowedField first and the corpus corrected me -- two of eight hits are `pub env: Vec<str:str>`, a map type the emitter cannot spell, the same footprint from a different wreck. This module's header states that rule and I broke it on the first try. Census now reads 22 / 1 / 0 / 1 / 8 with all five shapes firing on the control. Two new unit tests: one asserting both wrecks are caught, one asserting a path type and a nested generic are not. Refs #3243 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
enabled auto-merge (squash)
September 5, 2026 03:36
This was referenced Sep 5, 2026
fix(rust): lower Zig's undefined to Default::default() (+2) — NOT auto-merged, needs your call
#3223
Closed
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Sep 5, 2026
Contributor
PR DashboardGenerated at: 2026-09-05 05:06:38 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
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.
An inline
#comment on a struct field consumes the rest of the line and thedeclaration that follows it. The following field is deleted from every backend, and
both
parseandtypecheckaccept the spec.Five lines, and a field disappears
t27c parset27c typecheckgen-rustpub a: Floatb:String,— one fieldgen(Zig)a: Floatb:String,— one fieldgen-cFloatb:String a;— one fieldAll three backends agree, and all three are wrong the same way. Field
bis gone.A 2×2 that killed my first hypothesis
I first thought this needed a non-primitive type. It does not:
u8u8 # noteFloatFloat # noteMy earlier probe looked healthy only because the commented field was the last one,
so there was nothing left to swallow.
Measured on the corpus
specs/tri/pipeline/pipeline_parallel.t27loses four declarations to one comment:Durable evidence was already on disk: 11 seal files under
.trinity/seals/arenamed after the wreckage rather than after a module —
"[]const u8",Str = "",,String # phi, trinity, gematria, evolution, safety. Each points at a spec thatexists and already has a correctly-named seal, so they are extra seals created from a
parse artifact.
Shipped with it: a new shape in
tri misreadrust: pub a: Xb:Y,— a bare colon inside a type. A Rust type never has one; apath spells its separator
::.It is named for what the output shows, not for a cause, and that took a correction:
I called it
RustSwallowedFieldfirst, and the corpus answered with two of eight hitsbeing something else —
pub env: Vec<str:str>, a map type[str: str]the emittercannot spell. Same footprint, different wreck. The module's own header says to name a
shape by the output because the intent is exactly what was lost, and I broke that rule
on the first try.
The census now reads 22 / 1 / 0 / 1 / 8 with all five shapes firing on the control.
Not proposed here
The repair is in the lexer or the field parser, which is further upstream than
anything this pass has touched, and the correct behaviour of
#inside a declarationis a language question rather than a mapping one.
Refs #3243