Order discovered variants by name, not by interning order (fixes #175)

[typeless]

discover_variants ended with std::sort(result.begin(), result.end()) on a Vec<StringId>. StringId is an enum class over the interning handle and the names are interned in read_directory order, so the sort ordered by raw readdir order — the same defect as #171 (fixed in #174), at the second and last site that reads a directory into StringIds and treats handle order as name order.

Its one consumer is the build-directory hint, so the damage is cosmetic — this order never reaches %f, command identity, or anything persisted — but the same tree listed its candidates differently on different machines.

Measured

Six build dirs enumerating (ls -U) as yankee mike charlie bravo alpha zeta:

before: Error: no build directory specified; found: build-yankee, build-mike, build-charlie, build-bravo, build-alpha, build-zeta
after:  Error: no build directory specified; found: build-alpha, build-bravo, build-charlie, build-mike, build-yankee, build-zeta

Test

Same shape as the #171 regression test: it interns the names in reverse-lexicographic order before scanning, so handle order is deterministically the reverse of name order rather than whatever the filesystem happens to return. Observed failing first:

test_layout.cpp:234: FAILED:
  REQUIRE( found == std::vector<std::string_view>(names.begin(), names.end()) )
with expansion:
  { "dvar_zeta", "dvar_mike", "dvar_bravo", "dvar_alpha" }
  ==
  { "dvar_alpha", "dvar_bravo", "dvar_mike", "dvar_zeta" }

Class closed

The remaining std::sort calls over StringId — in cmd_build.cpp, context.cpp, scheduler.cpp, and glob_expand_all's exclusion list — are sort+unique or binary_search set structures, where handle order is order-agnostic by construction. cmd_show.cpp:173 and multi_variant.cpp:76 already sort through pool.get. No index version bump: nothing here is persisted.

make test green (142310 assertions, 617 cases, 32 e2e shards); make tidy and make iwyu clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TLob4Ef3qyMd3Dnp9q3XmA

[github-actions]

PR metrics

Performance (gcc example, Linux)

Workload	Instructions	CPU time	Page faults	D1 miss	LL miss	Wall	Peak RSS
parse	1074 M (+0.1%)	0.48 s	14.1 k	0.8%	0.1%	0.514 s	30.8 MB (-0.1MB)
dry-run	1792 M (+0.3%)	0.6 s	16.6 k	0.9%	0.1%	0.611 s	40.1 MB (+0.3MB)

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	5818
Files changed	0
Files in index	6087
Graph edges	367913
Index size (bytes)	7264970
Implicit deps	330624
Hash computations	0
Hashes skipped (stat cache)	5818
Stat calls	5869
Parse time (ms)	500.7
Total time (ms)	601.9
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.
Timing deltas suppressed: baseline ran on different hardware (AMD EPYC 9V74 80-Core Processor).

Binary size (Linux)

Binary	.text	.data	.bss	File
putup	496.5 KB (+0.5%)	1.7 KB	98.7 KB	583.9 KB (+0.2%)

Test coverage (lines)

Overall	Median file	Min file	Max file
86.6%	94.9%	0.0% src/platform/path-posix.cpp	100.0% include/pup/core/arena.hpp

103 files · 14986/17313 lines covered

Deltas vs main@1738aa715.

Updated for 02533ff

[typeless]

Adversarial review of this PR found that its claim 2 — that the remaining std::sort calls over StringId are "order-agnostic by construction, hence correct as written" — is false at two of the audited sites, both of which are live bugs on main:

• Exported environment variables are silently dropped from the child process when declared out of name order #183 — src/exec/scheduler.cpp:62 sorts by handle, :44 binary-searches by name. Exported environment variables are silently dropped from the child process. Reproduced: three export lines in reverse-lexicographic order lose all three variables, exit 0.
• import VAR silently loses its cached value across builds when imports are declared out of name order #184 — src/cli/context.cpp:677 sorts by handle, src/graph/builder.cpp:1305 binary-searches by name. import VAR loses its cached value, which changes rendered command text and therefore command identity.

Neither is introduced by this PR — both are pre-existing — but the audit in the PR body cleared them, and claim 1 ("the second and LAST site") is wrong as a result. The code change here is still correct; the reasoning in the description was not.

The general fix is #185.