gen-c: give an unannotated array literal a real element type - #3460
Merged
Conversation
Closes #3459 var w = [W{.code=1}, W{.code=2}]; __auto_type w = { (W){ .code = 1 }, (W){ .code = 2 } }; error: cannot use '__auto_type' with initializer list in C 1729 of them: the LARGEST single error class in the generated C corpus, more than twice the next (992 `expected expression`). Under clang's default cap the same class reads as 97. The repair existed -- W699 rung 3 -- and required the array literal to carry its own `extra_type`. `[W{...}, W{...}]` does not: the type sits on the CHILD, each element being a named struct literal. The condition now looks there, and the element type is taken from the first element when the array has none. The same arm carried the `is_primitive` gate, THIRD instance of W583. It lists only the integer scalars, so `[_]f64{...}` would have emitted `f64 x[2]`. MEASURED, whole corpus, -ferror-limit=0: errors 15021 -> 14738 __auto_type with initializer list 1729 -> 1401 files that compile 302 -> 303 files better 15 EIGHT FILES' COUNTS ROSE AND ALL EIGHT ARE UNMASKING, checked rather than assumed. An error-typed variable silences every diagnostic about its USES: while `w` had no valid type, clang reported nothing about `w.field` or `w[i].len`. Four of the eight name an element type that is absent from the generated header entirely -- a separate defect -- and the other four surface real downstream errors: `no member named 'len' in 'struct Item'`, `member reference type 'Item *' ... did you mean to use '->'`. In both groups the declaration is now correct and the count rose because clang can see past it. A MUTANT SURVIVED BECAUSE MY TEST USED THE WRONG SPELLING. Restoring the `is_primitive` gate broke nothing: the test declared `var x : [2]f64`, an ANNOTATED local, which takes a different branch entirely. `[_]f64{...}` is the form that reaches this arm. Rewritten, and the mutant dies. Three mutants, three dead. Residual, named rather than implied: `var x = [1.0, 2.0]` -- a bare list of numeric literals with no element type anywhere -- still takes `__auto_type`. 1401 of the class remain, and recovering a type there needs literal-kind inference rather than a lookup. 38 seals refreshed in the same commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
enabled auto-merge (squash)
September 8, 2026 03:44
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
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 #3459
1729 of them — the largest single error class in the generated C corpus,
more than twice the next (992). Under clang's default cap the same class reads
as 97.
Why the existing repair missed it
W699 rung 3 already handles this and required the array literal to carry its
own
extra_type.[W{…}, W{…}]does not — the type sits on the child,each element being a named struct literal.
The same arm carried the
is_primitivegate, third instance of W583: itlists only the integer scalars, so
[_]f64{…}would have emittedf64 x[2].Measured —
-ferror-limit=0__auto_typewith initializer listigla/race/ternary_gemm562 → 437 ·ternary_mac208 → 168 ·math/property_test_template43 → 5.Eight files rose, and all eight are unmasking — checked
An error-typed variable silences every diagnostic about its uses. While
whad no valid type, clang said nothing about
w.fieldorw[i].len.(
TernaryWeight,Cell,Assignment) — a separate pre-existing defect;no member named 'len' in 'struct Item',member reference type 'Item *' … did you mean to use '->'.In both groups the declaration is now correct and the count rose because clang
can finally see past it. This is the sharpest form of the non-monotonicity from
the previous pass.
A mutant survived because my test used the wrong spelling
Restoring the
is_primitivegate broke nothing — the test declaredvar x : [2]f64, an annotated local, which takes a different branchentirely.
[_]f64{…}is the form that reaches this arm.is_primitivegate restoredFull suite: 2634 passed, 0 failed. 38 seals refreshed in the same commit.
Residual
var x = [1.0, 2.0]— a bare list of numeric literals with no element typeanywhere — still takes
__auto_type. 1401 of the class remain, andrecovering a type there needs literal-kind inference rather than a lookup.
Named rather than left implied.