Conversation
… passed by not compiling
Fifteen `bootstrap/tests/c_*.rs` files each carried a hand-copied
.args(["-std=c11", "-ferror-limit=0", "-fsyntax-only", "-x", "c"])
`-ferror-limit=` is clang's. CI runs Ubuntu, where `cc` is gcc, and gcc
refuses it:
cc: error: unrecognized command-line option '-ferror-limit=0'
That breaks the two assertion shapes in OPPOSITE directions. Files asserting
`!stderr.contains("error")` fail, because the REFUSAL contains the word --
23 tests, reported by the ratchet as "the failing set grew by 23". Files
counting `file:line:col: error: ` lines pass, because `cc: error:` has no
line:col, so the count is zero and nothing was ever compiled. Green there
meant the C backend was untested, not correct, and that half was invisible.
The flag is not decoration -- clang stops after 20 errors and these tests
assert over the whole diagnostic set -- so it is chosen, not dropped.
`bootstrap/tests/common/mod.rs` probes `cc` once with an empty translation
unit and takes `-ferror-limit=0`, else `-fmax-errors=0` (gcc's spelling of
the same thing), else neither. A missing flag must never read as a broken
header.
`c_static_array_params` was never about the flag. It asserts the diagnostic
names `-Warray-bounds`, which is clang's name, and the CI log shows its
`got:` followed by an empty line. Measured on both compilers:
clang -fsyntax-only -> [-Warray-bounds]
gcc -fsyntax-only -> silence; it runs no analysis pass
gcc -c, even at -O0 -> [-Wstringop-overflow=]
Both the flags and the name differ, so it now asks instead of naming: a
hand-written undersized `[static 4]` call plus a correctly-sized control,
take the tag the first provokes and the second does not, then demand that
tag of the generated header. The control is what stops it selecting a tag
that fires on anything. It panics rather than skips when no candidate works
-- this file exists to prove the spelling CHECKS something.
`scripts/ci/check-cc-args.mjs` keeps the choice in one place, and runs in the
ratchet job, which already watches `bootstrap/**`.
Census: tools/census/shell.txt moves `run: steps` 275 -> 276, and "the
runner does" 254 -> 255. That is the one gate step added by this commit; no
other census moved.
Verified with a real gcc 15 standing in as `cc`, from a clean master base:
19 targets, 109 tests, 0 failures. gcc's genuine errors DO match the
`file:line:col: error: ` shape, so the vacuous files now check for real
rather than merely stopping being red.
Refs #4542
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
This was referenced Sep 21, 2026
Merged
…alone Refs #4542 `tri harness scratch` caught it: every test in a binary shares one pid, so `t27-cc-flags-{pid}` is one directory for four tests -- and the test that uses it deletes the whole thing on the way out. Nothing has gone wrong yet because only one of the four writes there, but the gate judges the key, not today's luck, and it is right to. A counter AND the pid, which is the gate's own advice and not belt-and-braces: the counter separates this binary's tests from each other, and the pid separates two concurrent runs sharing $TMPDIR. tri harness scratch --gate -> 114 files read, none cargo test --test cc_flags -> 4 passed
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-21 14:44:58 UTC
Summary
Seal Status
|
gHashTag
added a commit
that referenced
this pull request
Sep 21, 2026
…mitted both (#4558) Fixes #4557 `state_after` and `retry_allowed` were each declared twice in specs/automation/crm-duet.t27, byte-identical down to the comment. `t27c check` had been saying so all along -- "every backend rejects a redeclaration" -- and it was right. What it did not do was stop anything: the warning is not an error, `gen-c` exits 0, and the emitted header carries both definitions. cc -std=c11 -fsyntax-only before -> error: redefinition of 'state_after' cc -std=c11 -fsyntax-only after -> that error is gone t27c check before -> 0 errors, 2 warnings t27c check after -> 0 errors, 0 warnings tools/dupe_scan.py after -> no new duplicate, no known group grew The deletion keeps the pair that sits with the module's other function declarations. The spec's 12 tests are unchanged and still resolve. This is master's red, not either open PR's: #4541 and #4551 both fail `duplicate-bodies` on this file, which neither of them touches.
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 #4542
The defect
Fifteen
bootstrap/tests/c_*.rsfiles each carried a hand-copied argument listcontaining
-ferror-limit=0. That is a clang flag. CI runs Ubuntu, whereccis gcc, and gcc refuses it:It breaks the two assertion shapes in opposite directions:
assert!(!stderr.contains("error"))errors()filteringfile:line:col: error:cc: error:has no line:col → count 0The second half is the worse one, and it was invisible. Green there meant the C
backend was untested, not correct.
The fix
One place decides, replacing fifteen copies —
bootstrap/tests/common/mod.rsprobes
cconce with an empty translation unit and takes-ferror-limit=0,else
-fmax-errors=0(gcc's spelling of the same thing), else neither. Amissing flag must never read as a broken header, and the flag is not
decoration: clang stops after 20 errors and these tests assert over the whole
diagnostic set.
c_static_array_paramswas never about the flag — it names clang's-Warray-bounds, and the CI log shows itsgot:followed by an empty line.Measured on both compilers:
-fsyntax-only[-Warray-bounds]-fsyntax-only-c, even at-O0[-Wstringop-overflow=]Both the flag set and the warning name differ, so it now asks instead of
naming: a hand-written undersized
[static 4]call plus a correctly-sizedcontrol, take the tag the first provokes and the second does not, then demand
that tag of the generated header. The control is what stops it selecting a tag
that fires on everything. It panics rather than skips when no candidate works —
this file exists to prove the spelling CHECKS something.
scripts/ci/check-cc-args.mjskeeps the choice in one place. It runs in theratchet job, which already watches
bootstrap/**, and was verified to fail on adeliberately reintroduced copy.
Verified
Against a real gcc 15 standing in as
cc, from a clean master base:19 targets, 109 tests, 0 failures. All 7 previously-failing targets green.
gcc's genuine errors do match the
file:line:col: error:shape, so thepreviously-vacuous files now check for real rather than merely stopping being
red.
Census
tools/census/shell.txtmovesrun: steps275 → 276 and "the runner does"254 → 255 — the one gate step this PR adds. No other census moved.