Add shared tccbin conformance test suite#27924
Conversation
thirdparty/tccbin_tests/: a single, shared home for the compatibility tests that verify a platform's prebuilt tcc + libgc.a pairing (from vlang/tccbin) actually works, instead of each platform branch there maintaining its own disconnected, ad hoc checks (or none at all). - shared/: platform-agnostic tests every branch is expected to pass identically (hello-world with GC init, a GC-heavy allocation test, and confirming a genuine crash is still caught and not swallowed). - platform/<name>/: a small bucket for tests that are legitimately platform-specific (currently just platform/windows/crash_message.c, which checks tcc's own SEH diagnostic wording - a Windows-only implementation detail). - run.ps1 (Windows) / run.sh (POSIX, unverified - no non-Windows tcc build to test it against yet): small runners taking a tcc path and that platform's link flags, so nothing platform-specific is baked into the shared test logic itself. windows-amd64's tccbin branch (PR vlang/tccbin#67) is the reference adopter - see this directory's README for the shape other platform branches would copy.
|
@codex review |
Built tinycc from this same source natively on Linux (WSL/Ubuntu
24.04, gcc 16, ./configure && make install), linked the shared tests
against libgc-dev 8.2.6 from apt, and ran run.sh for real - all three
shared tests pass, stress-tested over 10 consecutive runs with no
flakiness. Updates the README, which previously (accurately, at the
time) flagged run.sh as unverified.
Not a full replication of vlang's actual Linux tccbin build (that
already has its own working, scripted pipeline via
thirdparty/build_scripts/thirdparty-linux-amd64_{tcc,bdwgc}.sh) - this
was specifically to verify the test *runner* script itself works
correctly on POSIX, using apt's libgc-dev as a quick stand-in rather
than building BDWGC from source to match exactly.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 39d05c718d
ℹ️ 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".
Three P2 findings, all confirmed against the current tree and fixed: - run.sh was committed as mode 100644 (not executable), so `./run.sh` as documented/used in CI would fail with "Permission denied" on any real POSIX filesystem (reproduced via a fresh git-archive extract onto WSL's native ext4 - /mnt/* NTFS mounts mask this, since DrvFs synthesizes rwx regardless of the tracked mode). Set via `git update-index --chmod=+x`, since there's no native chmod semantics to pick up from the Windows-side file. - The adoption guide told platforms with a prebuilt libgc.a to skip checking out thirdparty/libgc entirely - but no platform branch bundles its own gc.h (confirmed: none exists anywhere under thirdparty/tcc in the windows-amd64 branch), so the *headers* are needed unconditionally to compile the mandatory shared tests. Only thirdparty/libgc/gc.c (the source) is conditional on whether the platform rebuilds libgc.a from scratch. Clarified. - README.md:57 was 162 chars against AGENTS.md's documented 100-char Markdown limit; `v check-md` confirmed the failure and the fix (wrapped into a fenced code block). Both from Codex, vlang#27924 pullrequestreview-4767463437.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6bd7afbb03
ℹ️ 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".
- run.ps1: read stdout async while reading stderr sync, instead of ReadToEnd()-ing both sequentially - a process writing enough to the stream read second to fill its pipe buffer before the first stream closes would deadlock forever, since nothing drains the second stream while blocked on the first. Reproduced locally with a test program that only writes to stderr (15s hang), fixed, reverified (completes immediately, no regression in the 4-test suite). - run.ps1: use -cnotmatch instead of -notmatch for the expected- substring check - -notmatch is case-insensitive by default in PowerShell, making run.ps1 laxer than run.sh's case-sensitive `case` pattern match and able to miss a diagnostics-wording regression that only changes case. Reproduced (differently-cased substring wrongly "matched"), fixed, reverified (mismatched case now fails, exact case still passes, suite still 4/4). - run.sh: guard `work=$(mktemp -d)` with `|| exit 1` - an unguarded failure left $work empty, so exe="$work/$name.exe" silently became "/name.exe" (filesystem root). Reproduced via WSL with TMPDIR pointed at a nonexistent directory: the script proceeded, tried to write test binaries to /gc_alloc.exe and /hello.exe, and the crash test even produced a false PASS (wrong-reason nonzero exit) masking the real failure. Fixed, reverified (script now exits 1 immediately instead of limping along with a bogus work dir). All from Codex, vlang#27924 pullrequestreview-4767856781.
|
@codex review |
|
Codex Review: Didn't find any major issues. You're on a roll. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
… static libgc.a, XFAIL) TCC on macOS arm64 cannot yet link the Clang-built static libgc.a (see README.md), so this mirrors the dynamic libgc.dylib + rpath path V itself already uses on this platform (vlib/builtin/builtin_d_gcboehm.c.v) instead of skipping GC-dependent tests. hello.c and gc_alloc.c (both GC-dependent) run against libgc.dylib as the blocking lane; crash.c (no GC) runs unconditionally. A separate libgc.a lane is kept as a temporary, explicit XFAIL (continue-on-error) until static linking is supported, rather than silently dropped. Mirrors the thirdparty-windows-amd64 reference adopter (vlang#67) of vlang/v#27924's shared tccbin_tests suite.
|
@JalonSolov Review of CI failures are not related to this PR. Most are related to vlib/v3 formatting regression is out of scope for this PR. |
Summary
Adds
thirdparty/tccbin_tests/: a single, shared home for compatibilitytests that verify a platform's prebuilt tcc + libgc.a pairing (from
vlang/tccbin) actually works as a C
compiler + GC backend.
Why
Each
thirdparty-<platform>branch invlang/tccbinis an independentorphan branch with its own binaries and no shared history, so there was
no single place testing this consistently across platforms - a
regression could land on one platform's rebuild and go unnoticed unless
someone happened to test that specific platform by hand. This came up
concretely while bumping the windows-amd64 branch's tinycc version
(vlang/tccbin#67): two real
bugs (a stale
libgc.aABI mismatch, and a tcc exception-handling falsepositive) were only caught by writing ad hoc tests for that one PR, with
nowhere reusable to put them afterward.
What's here
shared/: platform-agnostic tests every branch is expected to passidentically - hello-world with GC init, a GC-heavy allocation test,
and confirming a genuine crash is still caught and not swallowed.
platform/<name>/: a small bucket for tests that are legitimatelyplatform-specific. Currently just
platform/windows/crash_message.c,which checks tcc's own SEH diagnostic wording - a Windows
implementation detail other platforms aren't expected to reproduce.
run.ps1(Windows) /run.sh(POSIX) - both verified, see below.README.md: the test-file contract and an adoption guide for otherplatform branches.
Testing
run.ps1is exercised for real byvlang/tccbin#67 (windows-amd64,
the reference adopter) - see that PR's CI for a passing run built
entirely from source on a
windows-latestGitHub Actions runner:https://github.com/quaesitor-scientiam/tccbin/actions/runs/30035579401
run.shwas verified separately: built tinycc from source natively onLinux (WSL/Ubuntu 24.04, gcc 16,
./configure && make install), linkedthe shared tests against
libgc-dev8.2.6 from apt, and ranrun.shfor real - all three shared tests pass, stress-tested over 10
consecutive runs with no flakiness. (Not a replication of vlang's
actual Linux tccbin build, which already has its own working pipeline
via
thirdparty/build_scripts/thirdparty-linux-amd64_{tcc,bdwgc}.sh-this was specifically to verify the runner script itself works on
POSIX.) Not tested on macOS or any BSD yet.
Note that PR #67 currently points its checkout of this directory at
this fork branch (since it isn't merged yet) - it'll need updating to
a real vlang/v commit once/if this lands.