Give the test suite one temp root instead of fourteen ambient guesses

[typeless]

Test-infrastructure only — no src/ change, no Tupfile change, so the build graph is untouched and no bootstrap regeneration is needed.

The issue was misdiagnosed, and the correction is the fix

It is filed as a 32-way race on fixed-name temp paths. It is neither a race nor a name collision.

putup runs rule commands hermetically: base_child_env() (src/platform/process-posix.cpp:52) builds a child environment containing only PATH, and the scheduler uses it (src/exec/scheduler.cpp:775). So no rule command sees TMPDIR, std::filesystem::temp_directory_path() falls back to bare /tmp, and on a machine where /tmp is read-only the scratch write fails. Deterministic, in one sequential process:

$ env -u TMPDIR ./build/test/unit/putup_test 'v8 roundtrip with operand sections'
test_index.cpp:1237: FAILED:
  REQUIRE( write_result.has_value() )
Catch will terminate because it needed to throw an exception.
terminate called without an active exception
  SIGABRT - Abort (abnormal termination) signal

The suite is built -fno-exceptions, so the SIGABRT is Catch2 aborting the failed REQUIRE — the issue's "two unrelated failures" are one event, and both appear in that single output. Which shard reported it varied by scheduling, which is what made it look like contention. Running the fast rule and all 32 shards concurrently by hand passes, three rounds for three rounds.

CI stays green because its /tmp is writable, so the same environment stripping is harmless there.

What changed

Every test that needs scratch now calls pup::test::temp_root() (new header-only test/unit/temp_root.hpp), which resolves one writable base per process — ambient temp, then /var/tmp, then /dev/shm, each probed by actually creating a directory — and hands out unique paths beneath it. 14 sites across 12 files.

The hardcoded "/tmp/claude" fallback in the e2e fixture is deleted, not generalized. It was an earlier repair of this same failure, applied in the one file where someone noticed it; it fixed that instance and left the class alive, which is why this issue exists.

Two sites are deliberately left alone and said so rather than skipped silently: a realpath comparison that needs a real system path to exist rather than be writable, and the e2e fixture data.

Two things worth reading in review

The grep that finds this class does not find all of it. Two sites spelled it differently — getenv("TMPDIR") with a bare "/tmp" literal fed to mkdtemp, and "/tmp" used as a working directory. The first was the only test still failing after every known site had been converted, and cost a full make test cycle to find.

Writable is not the constraint; writable and outside any putup project tree is. The first version of the fix fell back to the current working directory. Every per-test run went green, then make test failed in shards 17 and 23 with Attempting to create files the build does not own — shards run with cwd = test/runner, which is itself a putup project, so putup correctly refused scratch created there. That constraint is now recorded where the resolution happens.

Verification

Gate	Result
make test	exit 0 — 170219 assertions, 835 cases, 32 shards
full suite, one process, env -u TMPDIR	exit 0
make format / make format-check	exit 0
make tidy	exit 0
make iwyu	exit 0 — no dead includes
make spec-check	exit 0 — 105 requirements, 0 gaps

Five formerly failing tests were quoted red before the change and green after. Exit statuses were captured on their own line, never through a pipe. Pair-reviewed by a non-Opus partner against a hash-verified snapshot: no blockers.

Known, recorded rather than fixed

/dev/shm can be mounted noexec, and the e2e shell fixtures compile and then execute binaries in their scratch tree. On a host where ambient temp and /var/tmp are both unwritable and /dev/shm is noexec, that fails confusingly rather than cleanly.

It is left as built deliberately: on the machine this issue is about, ambient temp and /var/tmp are both read-only and /dev/shm is the candidate that works — the full suite, including every fixture that compiles and runs a binary, passes from there — so dropping it would un-fix the issue on the machine that has it. An honest exec probe is not cheap either: Linux access(X_OK) does not reflect a noexec mount, so probing truthfully means fork+exec at startup in all 33 test processes.

Fixes #397

🤖 Generated with Claude Code

https://claude.ai/code/session_014wx1bWwRf23eFT82y9D641

[github-actions]

PR metrics

Performance (gcc example, Linux)

Workload	Instructions	CPU time	Page faults	D1 miss	LL miss	Wall	Peak RSS
parse	1698 M	0.59 s	14.9 k	0.7%	0.1%	0.596 s	34 MB
dry-run	2367 M	0.69 s	16.3 k	0.8%	0%	0.708 s	39.1 MB (+0.1MB)

Deterministic signals: instructions (cachegrind-simulated instruction reads — exact across runs, no PMU needed), page faults, peak RSS, and the cachegrind D1/LL miss rates. CPU time is user+sys from time(1).

Internal statistics (gcc example, up-to-date dry run)

Metric	Value
Tupfiles parsed	24
Commands	3545
Commands scheduled	0
Files checked	5834
Files changed	0
Files in index	6102
Graph edges	381415
Index size (bytes)	7683630
Implicit deps	344126
Hash computations	197
Hashes skipped (stat cache)	5636
Stat calls	5885
Parse time (ms)	531.3 (-4.8%)
Total time (ms)	678.2 (-5.4%)
Runner CPU	AMD EPYC 7763 64-Core Processor

Counters from putup -n --stat on the fully-built gcc example (up-to-date dry run): deterministic work measures — a jump in commands scheduled, hash computations, or stat calls is a real behavior change, not noise. Timings are the minimum over repeated runs, compared only against a baseline from the same CPU model; the counters are the regression signal.

Binary size (Linux)

Binary	.text	.data	.bss	File
putup	565.4 KB	2.3 KB	98.7 KB	671 KB

Code churn (whole codebase, last 30d)

Files	Lines written	Still present	Churned	Churn rate
139	11314	9456	1858	16.4%

Of the lines written across the codebase in the last 30 days, how many are already gone — work that was written and then discarded or rewritten inside the same window. This is the state of the tree including this PR, not a measure of the PR itself. Only code we write is counted: tests, examples, vendored and generated files, CI plumbing and prose are excluded. 5268 lines were deleted in the window in total, most of them older than it.

Where the churn is

File	Lines written then discarded
src/cli/cmd_build.cpp	614
src/graph/scanners/clang_cl.cpp	295
src/graph/scanners/gcc.cpp	113
src/cli/context.cpp	82
src/graph/builder.cpp	70
src/core/layout.cpp	69
src/graph/scanners/dep_words.cpp	64
src/core/new_delete.cpp	63
src/platform/file_io-posix.cpp	42
src/cli/strict_checks.cpp	36

Test coverage (lines)

Overall	Median file	Min file	Max file
88.1%	96.4%	14.7% include/pup/parser/token.hpp	100.0% include/pup/core/arena.hpp

102 files · 16614/18854 lines covered

Deltas vs main@26ddb6105.

Updated for 8027ca8