ci: probe the EBADARCH architectures, after the arch-flag hypothesis failed

[Shepdesign]

⚠️ Rewritten on 2026-09-25 — the hypothesis this PR opened with was wrong

It shipped ONLY_ACTIVE_ARCH=YES on the theory that an arm64 tracer was failing in an x86_64 compile. Run 36093785096 falsified it. The flag is reverted; what replaces it is a diagnostic, not another guess. The original body predicted this as outcome (c), so at least the prediction was honest.

Based on #24, not main. Retarget when #24 merges.

What the failed experiment established

ONLY_ACTIVE_ARCH=YES worked exactly as specified — the only architecture compiled was arm64, no x86_64 slice anywhere in the log — and Bad CPU type still occurred. So the arch mismatch was not the cause.

The theory is dead on its own terms too. I read the Mach-O fat header of tools/osx64/libtrace.dylib out of the 2.27.1 osx64 bundle:

magic: 0xcafebabe
FAT binary, 2 slices:
   - x86_64
   - arm64

It was never missing a slice for the build. I inferred that mismatch from the …/CodeQL/2.27.1/arm64/… tool-cache path plus a SwiftCompile normal x86_64 line, and never measured it — the same mistake as the 2.27.0 version claim in #24, one step further along.

What it settled, which is the actual win

There is one blocker, not two. #24 recorded the 'self' is immutable errors as possibly independent, cause unestablished. This run named the cause outright:

ViewModifiers.swift:101:21: error: external macro implementation type
'SwiftUIMacros.StateMacro' could not be found for macro 'State()';
compiler plugin '…/usr/bin/swift-plugin-server' could not be loaded:
Bad CPU type in executable

@State is itself a macro, expanded by the same plugin server. When the plugin will not load, @State does not apply, so its nonmutating set never exists — and triggerRefresh.toggle() at :114 and the assignment at :117 become "cannot use mutating member on immutable value". They are downstream of the one failure and need no separate fix. That removes the "second blocker" from the picture entirely.

	932b589 universal	6682385 universal	8ad8ad4 arm64-only
Bad CPU type	14	0	2
'self' is immutable	4	4	4
architectures compiled	arm64, x86_64	arm64, x86_64	arm64

What this PR now does

Replaces the flag with one continue-on-error step that prints lipo -archs for swift-plugin-server, swift-frontend and $DYLD_INSERT_LIBRARIES. The build command is byte-identical to main's again.

It is an instrument, not a fix. The remaining candidate is an architecture on neither list — arm64e, since dyld refuses an arm64 library inserted into an arm64e process, and Xcode 27 moving helpers to arm64e would explain why this began when the image moved. That is measurable on the runner in one cycle, and I am not going to argue it from here, because arguing it from here has now been wrong twice.

The probe also records in the workflow what is already ruled out, so nobody re-tests it: libtrace carries both slices, and building one architecture does not help.

Demo

The probe's output in the next Analyze (swift) log is the deliverable. Analyze (swift) will still fail — the probe does not fix anything and cannot, by design.

$ python3 -c "import yaml; …"                      # 9 steps now (probe added)
YAML OK, steps: 9
$ git diff origin/main -- .github/workflows/codeql.yml | grep '^[+-]\s*xcodebuild'
                                                   # empty: build command unchanged
$ python3 -m unittest discover -s scripts/tests
Ran 110 tests in 0.040s
OK

Rule check

Non-negotiable 5 — serves its enforcement by trying to make the gate able to run at all. No app behaviour, no endpoint, Sources/ untouched, contents: read unchanged. The probe only reads binary architectures already on the runner; it sends nothing anywhere.

Brand check

None. No UI, no assets, no tokens.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UuHYhiqbmF4dT7sq8a6AYm

[Shepdesign]

Correction: I reported this fixed. It was a fail-open.

bc8af8b's message and my report both said arch -arm64 fixed the EBADARCH failure. It did not. It removed the tracer, and 9e15bb4 reverts it.

/usr/bin/arch is SIP-protected, and dyld purges DYLD_* across a restricted exec — so arch -arm64 xcodebuild ran with no libtrace inserted at all. Run 36095774560 is what that looks like from the outside: the build succeeded for the first time all session, and then

Error: CodeQL could not process any code written in Swift.

	c5d7d6a	arch -arm64
Bad CPU type	2	0
'self' is immutable	4	0
build	fail	SUCCEEDED
code extracted	—	NONE

Three of those four read as a fix. The fourth is explained by nothing except the tracer being absent — and an untraced build passing is precisely what ci.yml does on every push. I had already written that down in this very file as the reason ci.yml is green, and then failed to apply it to my own result.

The "controlled comparison" I leaned on was not one. Holding runner: x86_64 fixed while changing the wrapper did not isolate the architecture — it removed tracing, which moves every signal at once. A comparison is only controlled if you can name what it holds constant, and I couldn't have: I never checked that the tracer was still attached.

What nearly shipped

Had database finalize not refused an empty database, this would have been a green CodeQL job that had seen no code. That is the fail-open this entire mechanism exists to prevent, and it would have come from the person maintaining it. CodeQL's own no-source-seen check is the only thing that caught it — not the gate, not the tests, not me.

That is the fourth distinct way this mechanism has been one step from reporting clean on nothing, and the first where I was the one holding the step.

Where this leaves the PR

• Build command byte-identical to main's again. The job is back to red on the known EBADARCH failure, which is the honest state — red on a real failure beats green on nothing.
• The banner now warns the next reader off arch specifically, with the four-signal table, instead of recommending it.
• The probe grows three lines that measure the purge rather than assuming it: DYLD_INSERT_LIBRARIES outside arch, under arch, and re-set past the arch boundary. That last one decides whether an arm64 parent is reachable at all — if the variable survives an explicit re-set, there may be a real version of this fix; if not, the arch route is closed and the remaining path is upstream.

Still true, and not affected by any of this

@State being a macro, so the 'self' is immutable errors are knock-on rather than a second bug — that came from a traced run and stands.

Also worth flagging: the exit code 0 but produced no further output failure I documented in bc8af8b appeared in both runs, but the build step failed in one and succeeded in the other. So it is not the blocker I took it for; it is noise that sometimes fails the step. That was a second thing I got wrong in the same commit, and it is now stated as unexplained rather than as a finding.

---

Generated by Claude Code

[Shepdesign]

Handoff — one measurement in flight, and how to read it

I'm standing down on this PR. Run 36096284681 (9e15bb4) is still going and carries the one open question. Its logs aren't served until the job finishes, so I could not capture the answer before stopping. It needs no further code from anyone — just reading.

In the Analyze (swift) log, find the probe step and look at three lines:

DYLD outside arch:      <path>          ← expect the libtrace path
DYLD under arch:        ???             ← THE ANSWER
DYLD re-set under arch: ???             ← the fallback

DYLD under arch	Meaning	What follows
<unset>	dyld purged it across the SIP-protected arch exec — confirms why arch -arm64 silently disabled tracing	check the third line
a path	the purge theory is wrong, and the untraced run has some other cause — re-open from there

And if the second line is <unset> but the third shows a path, an explicit re-set survives the arch boundary and there is a real version of the arm64 fix: arch -arm64 /usr/bin/env DYLD_INSERT_LIBRARIES="$DYLD_INSERT_LIBRARIES" xcodebuild …. If the third is also <unset>, the arch route is closed and nothing in this repo gets Analyze (swift) green — it needs Xcode's helpers to regain x86_64 slices, or the runner to stop translating, or CodeQL's tracer to handle the mismatch.

Verify before trusting any future green here. The lesson of bc8af8b is that this job can pass by seeing nothing. Any change that turns it green must also show a non-empty database — database finalize succeeding and the gate step actually running, not skipped.

State of both PRs

Neither is required for anything on main; the gate and its 110 tests landed in eae0e41 and are untouched by all of this.

• ci: probe the EBADARCH architectures, after the arch-flag hypothesis failed #25 — build command is byte-identical to main's. It is a probe plus comments. Safe to close.
• #24 — comments only, corrected diagnosis. Safe to merge or close.

What is established, all measured rather than argued

Fact	Evidence
swift-plugin-server, swift-frontend are arm64-only	lipo -archs on the runner
runner shell is x86_64 (Rosetta)	uname -m on the runner
libtrace.dylib is fat (x86_64 + arm64)	Mach-O fat header of the 2.27.1 bundle
@State is a macro — 'self' is immutable is knock-on, not a second bug	named in a traced run's error
trace = false cannot prevent injection	reproduced against 2.27.0
Swift has no build-mode: none	swift/codeql-extractor.yml
arch strips the injection — do not reach for it	run 36095774560, and the probe above

All of it is in the workflow banner, so nobody has to repeat today.

---

Generated by Claude Code