ci(macos-amd64): flip checked-in gate from must-stay-broken to must-pass

[quaesitor-scientiam]

Summary

Deliverable (B) of the macos-amd64 libgc-dylib-pairing plan, following vlang/v#27982 (deliverable A, merged): vlang/v's update_tccbin.yml now rebuilds libgc.dylib in lockstep with every tcc.exe rebuild for this platform, mirroring macos-arm64's already-proven dylib+rpath pattern, instead of silently preserving a stale libgc.a across every rebuild.

The verify the checked-in tcc.exe (as distributed, before rebuild) step previously hard-failed if the checked-in pair unexpectedly passed the conformance suite - because until now it genuinely could not (ancient v0.9.27 tcc.exe, broken libc.dylib symlink, static-only libgc.a). That assumption no longer holds and would immediately misfire the moment a correct pair is published.

This strengthens the gate; it does not relax anything. Split the single step into five, mirroring the shape already proven below for the freshly-rebuilt copy:

• verify the checked-in tcc.exe is executable (unchanged logic, split out)
• verify the checked-in libgc.dylib (new - independent symlink/install-name re-verification, same principle already applied in vlang/v's thirdparty-macos-amd64_bdwgc_validate.sh)
• verify the checked-in libgc.a is a well-formed x86_64 archive (adapted - now fat-or-thin aware via lipo -archs, since a pair published through vlang/v's amd64-native rebuild is expected to be a thin x86_64-only archive, unlike the FAT universal binary this replaces; lipo -thin fails outright on an already-thin input, so it's now only invoked when the archive is actually fat)
• run shared conformance tests against the checked-in pair (libgc.dylib, dynamic - blocking) (new - was previously untested against the static-only checked-in archive)
• verify no-GC fallback path against the checked-in pair (new)
• run shared conformance tests against the checked-in pair (libgc.a, static - XFAIL) (adapted from the old must-fail assertion - tcc's Mach-O archive-parsing limitation is a property of tcc itself vs. a modern-toolchain-built static archive, independent of whether that archive is checked-in or freshly rebuilt, so this lane is expected to keep failing this one specific way even after the dylib pairing lands, exactly as already proven for the freshly-rebuilt copy)

⚠️ This PR's own CI run is expected to fail against the current tip of thirdparty-macos-amd64. The checked-in pair hasn't been replaced by vlang/v#27982's producer-side fix yet - that publish is intentionally gated behind vlang/v's MACOS_AMD64_LIBGC_PUBLISH_UNLOCKED repo variable until this PR lands (to avoid the reverse problem: a correct pair getting auto-published by the monthly cron while this gate still expected brokenness). Merging this PR is expected to keep CI red on this branch until the real publish happens next - that's the intended state, not a bug in this PR.

Suggested sequence

1. Merge this PR.
2. On vlang/v, set the repo variable MACOS_AMD64_LIBGC_PUBLISH_UNLOCKED to true.
3. Dispatch vlang/v's update_tccbin.yml with publish=true force_rebuild=true, using the exact TinyCC/bdwgc/libatomic_ops SHAs already validated in vlang/v#27982's fork run, to push the real pair to this branch.
4. Confirm this workflow goes green against the newly-published commit.
5. Only then open the V selector PR (deliverable C, builtin_d_gcboehm.c.v).

Test plan

• YAML validated (yaml.safe_load) and every step's shell script syntax-checked (bash -n) locally - done.
• lipo -archs-based fat/thin detection logic verified in isolation for all four cases (fat with x86_64 present, thin x86_64, thin arm64-only correctly rejected, fat with reversed arch order) - done, lipo itself unavailable outside macOS so this couldn't be exercised end-to-end locally.
• Confirm this PR's own CI run fails as expected against the current (still-unpublished) tip.
• After the sequence above, confirm a subsequent run against the newly-published commit is green.

[quaesitor-scientiam]

CI results from the two runs so far, both against the current, still-unpublished tip of this branch - as noted above, this is expected to be red until the real publish happens:

• Run 1 (961ccb1): verify the checked-in libgc.dylib correctly failed - libgc.dylib isn't committed here yet. Everything past that point either skipped (default behavior) or cascaded into other expected failures. One gap found: the new libgc.a archive-validation step was also skipped by the dylib failure, so its new fat-or-thin lipo -archs logic never actually ran against a real archive in this pass.
• Fixed in e262322: gave that step if: ${{ !cancelled() }} (matching the pattern already used below for the no-GC/static-XFAIL lanes) so it validates independently of the dylib check - they're different files, one being broken shouldn't hide whether the other is fine.
• Run 2 (e262322): same expected dylib failure, but the archive-validation step now ran for real and passed - confirmed via its own log line: thirdparty/tcc/lib/libgc.a architectures: x86_64 arm64 (the legacy FAT archive this replaces), followed by a successful lipo -thin x86_64 extraction and ar/nm validation on that slice. This is the one piece of new logic here I couldn't exercise locally (no lipo outside macOS) - now empirically confirmed against the real checked-in archive.

Everything else in both runs is an expected, transient symptom of testing binaries that predate vlang/v#27982's publish, not a new bug:

• The checked-in pair's static-XFAIL step fails with the old known shape (0 passed, 3 failed, all three tests including crash) rather than the unresolved GC_init shape my code checks for - that's the ancient v0.9.27 tcc.exe's already-documented broken-libc.dylib-symlink issue (linking any extra archive on the command line triggers it, even for a GC-free test), not the archive-parsing limitation this lane exists to XFAIL. It'll match the expected shape once the real dylib-paired rebuild replaces these binaries, since that's a fresh, modern, amd64-native build with the same shape as the (also-)failing "rebuild libgc.a from current bdwgc source" lane below it currently short-circuits around.
• That "rebuild" lane's own static-XFAIL step likewise fails, cascading from install build dependencies/rebuild libgc.a being skipped (same root cause), so it ends up testing the still-old FAT archive too instead of a fresh rebuild.

No unexpected failures in either run - everything traces back to the single, correctly-identified root cause (the real pair hasn't published yet), plus one now-fixed gap in test independence.

[GGRei]

Great work, is exactly the gate we needed. Once it is merged, we will take care of the vlang/v side and the safe publication process. Thanks!

[GGRei]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Can't wait for the next one!

Reviewed commit: e26232240d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".