Symptom
native_link_cache::native_compile_skips_link_on_identical_second_build fails:
a second, byte-identical build is expected to hit the caches and instead misses
entirely.
build_cache: { "hit": false, "miss_reason": "source" }
codegen_cache: hits = 0 (expected 1)
miss_reason: "source" means the second build considered the source changed
when it had not.
Not a regression from the current release window
Confirmed with clean builds (cargo clean first — an incremental target dir
across checkouts produces false verdicts here):
| commit |
result |
83754818ea (Aug-31 release pin) |
FAILED |
b39778201b (current pin) |
FAILED |
b39778201b + #9372 + #9375 |
FAILED |
So it predates the window and is independent of #9226.
Why it went unnoticed
cargo-test-perry shards run only in the full tier, never on main. In the
Aug-31 full tier this test never executed: it appears in shard 6's enumeration
but never as Running tests/native_link_cache — the shard died earlier, on
fire_and_forget_fetch_survives_recompile. There is no baseline for it in
recent history.
Reproduces locally
macOS/aarch64 as well as ubuntu-latest:
cargo build -p perry -p perry-runtime-static -p perry-stdlib-static
RUST_TEST_THREADS=1 cargo test -p perry --test native_link_cache
(build the -static wrappers first — otherwise a stale archive yields a
commit-coherence refusal rather than a test result)
Worth checking
If the cache genuinely misses on an unchanged source in normal use, the cost is
not only this test — every incremental perry compile would be re-linking
needlessly. Worth confirming whether the defect is in the test's fixture or in
the cache key itself.
Blocking
full-suite-gate fails on it, so it blocks any release cut until fixed or
triaged.
Symptom
native_link_cache::native_compile_skips_link_on_identical_second_buildfails:a second, byte-identical build is expected to hit the caches and instead misses
entirely.
miss_reason: "source"means the second build considered the source changedwhen it had not.
Not a regression from the current release window
Confirmed with clean builds (
cargo cleanfirst — an incremental target diracross checkouts produces false verdicts here):
83754818ea(Aug-31 release pin)b39778201b(current pin)b39778201b+ #9372 + #9375So it predates the window and is independent of #9226.
Why it went unnoticed
cargo-test-perryshards run only in the full tier, never onmain. In theAug-31 full tier this test never executed: it appears in shard 6's enumeration
but never as
Running tests/native_link_cache— the shard died earlier, onfire_and_forget_fetch_survives_recompile. There is no baseline for it inrecent history.
Reproduces locally
macOS/aarch64 as well as
ubuntu-latest:(build the
-staticwrappers first — otherwise a stale archive yields acommit-coherence refusal rather than a test result)
Worth checking
If the cache genuinely misses on an unchanged source in normal use, the cost is
not only this test — every incremental
perry compilewould be re-linkingneedlessly. Worth confirming whether the defect is in the test's fixture or in
the cache key itself.
Blocking
full-suite-gatefails on it, so it blocks any release cut until fixed ortriaged.