Empty array literal is a value, not a slice type (seal moved, Architect-approved) - #3962
Merged
Merged
Conversation
…ves for it
`pub const SKILLS : [0]str = [];` generated `pub const SKILLS: [0]str = [];`,
which Zig rejects: "expected type expression, found ';'". The literal passed
through to the output verbatim.
`parse_bare_array_literal` bailed on `[` immediately followed by `]`. That guard
is right for a slice TYPE and keeps the pass linear, but a slice type always
names what it is a slice OF, so one more token separates the two cases: a
bracket pair followed by anything that is not an identifier or another `[` can
only be an empty list. The emitter needed the matching case, because an array
literal with no children and no element text fell into the comma-splitting path
and produced `.{ }` with a phantom element.
A single-element literal (`[7]`) is genuinely ambiguous with a dimension and is
deliberately left alone.
## Why the seal moved
FROZEN.md §5 step 2, as an Architect-approved hotfix — authorised explicitly for
this change.
M1 cargo build --release green
M2 no .t27 spec is touched by this PR
M3 cargo test --release 2715 passed, 0 failed — identical to the
same suite on this commit without the patch
M4 the repo has no tests/run_all.sh; the CI checks on this PR stand in for it
Old seal 7cab95c431bcbd7416fd5b18ab3a74ee5f274d92b3bc5446bfcbd72e22579604
New seal ace867b052b42b0ff74be3720a15448875bfc718363c71d847c0aeb1f2f5772e
## What it measurably does, and does not, do
Generated files emitting `= [];` fall from **227 to 1**, and the
"expected type expression" error class falls from 262 to 107.
The corpus pass count does **not** move: 279 before, 279 after, none gained,
none lost, measured by generating all 945 specs and running each under
`zig test` with a t27c built from this commit. The 226 files have a second
defect behind the first — `pub const TOOLS: [1]str = [tri/gen];`, a
single-element literal holding an unquoted path. That is the next layer, and it
is now visible because this one is gone.
Reported this way on purpose: the previous change to this corpus was announced
as a large win on numbers that came from a stale compiler and turned out to move
nothing at all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
Owner
Author
emit-bitexact / spec-guards / Corpus ratchet: not this changeAll three fail on the same pre-existing set of specs that do not parse — Verified rather than asserted. Generating all 945 specs with a So the patch introduces no generation failure. The three checks are red because master carries ~10 unparseable specs, which is a real defect and a separate one. The required checks — |
This was referenced Sep 17, 2026
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 #3960
pub const SKILLS : [0]str = [];generated= [];, which Zig rejects outright. The literal passed through to the output verbatim.parse_bare_array_literalbailed on[immediately followed by]— correct for a slice TYPE, wrong for a VALUE. A slice type always names what it is a slice of, so one token of lookahead separates them. The single-element case ([7]) is genuinely ambiguous with a dimension and is deliberately untouched.Freeze ceremony (FROZEN.md §5)
Architect-approved hotfix, authorised explicitly for this change.
cargo build --releaset27c parseon touched specs.t27spec is touchedcargo test --releasetests/run_all.shWhat it measurably does — and does not — do
Generated files emitting
= [];fall from 227 to 1. Theexpected type expressionerror class falls from 262 to 107.The corpus pass count does not move: 279 before, 279 after, none gained, none lost. Measured by generating all 945 specs and running each under
zig test, with at27cbuilt from this commit.The 226 files have a second defect behind the first:
A single-element literal holding an unquoted path. That is the next layer, and it is visible only because this one is gone.
Reported this way deliberately: the previous change to this corpus was announced as a large win on numbers produced by a stale compiler, and turned out to move nothing.