[ashhart]

A pull request's zig and zig-windows jobs now reuse main's test passes and compiles, C and C++ included, so they run only what the diff changed. Main still builds and tests every commit from scratch.

Why tests never reused a pass

Zig's build cache can reuse a passing test, but on CI it never did. Zig 0.17's check misses on any stat change to a declared input even when the contents match, and a checkout or a restored cache gives every file a new id. So every test binary, fixture and C or C++ source looked changed. The bug is ziglang/zig#37200. The fix (#37238) is on Zig's master, but no release has it yet, 0.17.1 included.

What changes

• tools/zig/zig_cache_restat.zig runs before the first build. A file a manifest records gets its new id only if its contents still hash to the recorded digest. A file whose contents changed is left alone, so Zig misses as it should. Zig's own library isn't patched, and C and C++ compiles reuse as well. If a Zig update changes the cache format, the step warns, the job rebuilds and reruns more than it needs to, and tools/zig/zig_cache_restat_test.py fails. That test runs on main, and on pull requests that change the tool, this workflow or Zig's version.
• Tests that read files while they run. A cached pass says nothing about a file a test opens at run time. A trace of every test run on Linux found these:
  • Four tests read fixtures, now declared in zig/build/test_reads.zig, so a changed fixture reruns them.
  • The goldens and the q35 launch check read whole folders, so they always run, because a directory input hashes only its entries' names.
  • The kernel symbols check always ran.
• Main stays cold. It restores no cache, so every commit on main is still checked from scratch. A pass that shouldn't have been reused shows on the next main run. That also keeps the cache at one build, so the shared-source part of the key is gone.
• -Drerun-tests is removed. It made every run of a test a side effect, so main saved no test results for a pull request to reuse.

Measurements

On a Mac, a full test, test-golden and fuzz-cortheon run, one run of each, on a loaded machine:

Fresh checkout, main's cache restored	Time	Redone
Cold, for comparison	680 s	everything
Nothing changed, without the tool	440 s	25 compiles, 316 test runs
Nothing changed, with the tool	86 s plus 7 s for the tool	0 compiles, 23 test runs
A core file changed	284 s	66 compiles, 82 test runs
A fixture changed	84 s	its tests reran (and failed, as they should)

The 23 test runs are the steps that always run, and the goldens take 60 of those 86 seconds. On Linux, with an earlier version that still recompiled C and C++, a restored run with nothing changed took 316 s, against 701 s cold.

This PR's own CI restored main's first save from #2252. That save holds compiles but no test results, so every test ran once here. Test passes start reusing once this lands and main saves its first run. What it shows for the tool:

Job	Records the tool updated	Time
zig-windows	427,677 in 1,713 manifests, 18 s	zig build test 13.9 min with every test run, against 24.6 cold
zig	305,485 in 429 manifests, 20 s	zig build test 12.4 min with every test run, against 11.7 cold on another runner. Linux time is mostly tests, and these logs carry no build summary
zig-macos-dev-tools	166,349 in 221 manifests, 11 s	zig build dev-tools 18 s, and the whole job 1 min, against a median of about 13 before #2252
release-paths	9,433 in 42 manifests	the whole job 2 min

The tool's own regression test ran here because this PR changes it: 2 minutes on Linux.

Not done here

• release-paths and the macOS dev tools run the tool too, but have no warm number yet.
• ci: collect native Linux host checks and guard exclusions #2095's wider host step reads more fixtures, so its tests need the same trace before it can reuse their passes.

The approach of updating a restored cache's records came from cosmic-lua's zig-restat. This tool is written from Zig's own cache code.

Test plan

• This PR's CI passes, and the tool's step logs updated records on Linux and Windows
• zig-windows compiles nothing in C or C++ that main's save already holds
• After landing: main saves, and the next pull request's test steps show cached for what its diff didn't touch