Probe consteval coverage in batched rounds across all headers

[philipcraig]

Closes #374.

Replaces one compile per probe point with batched rounds, and instruments every library header instead of just protocol.hh.

Timings

The CI probe step for the same 177 probe points, single runner unless stated:

Run	Probe points	Probe step
main (protocol.hh only)	83	10.1 min
#369 unsharded	177	36.3 min
#369 four shards	44 each	9.3–11.8 min per shard, 4× runner minutes
this PR	177	3.1 min

The whole job now takes 5 minutes, and timeout-minutes drops from 90 to 30.

Locally, against the one-compile-per-probe script from #369 with name_mangling_tests.cc added:

Script	Cores	Wall	Rounds
#369, one compile per probe	24	419 s	–
this PR	4	94 s	23
this PR, contiguous instead of interleaved batches	4	155 s	42

Both scripts report 150/177 probe points covered, with identical per-header LCOV records.

How

• Traps are keyed on (header index, __LINE__), so all headers are instrumented in one work directory and one -include file arms any subset of them.
• Each round arms every probe point not yet covered and compiles a translation unit once per batch. GCC reports every independent constant evaluation that throws, so one compile finds many points; a point masked by an earlier trap on its path surfaces in the next round once that trap is disarmed. Rounds stop when one finds nothing new (from jbcoe's prototype on the closed Instrument all consteval headers in coverage script #369 branch).
• Batches are interleaved rather than contiguous, so neighbouring probe points, which usually share an evaluation path, do not mask each other.
• Translation units are probed cheapest first (name_mangling_tests.cc is now included), so protocol_test.cc only ever arms what the cheaper ones left uncovered.
• Unarmed traps are if constexpr no-ops, so they cost the constant evaluator nothing.
• A compile that fails with no trap fired is reported as an instrumenter bug, which replaces the separate unarmed verify pass.
• The CI job is back to a single runner.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.57%. Comparing base (55268e1) to head (cef9446).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #386      +/-   ##
==========================================
+ Coverage   72.79%   74.57%   +1.78%     
==========================================
  Files          12       15       +3     
  Lines         838     1003     +165     
  Branches      221      221              
==========================================
+ Hits          610      748     +138     
- Misses         22       49      +27     
  Partials      206      206              

Flag	Coverage Δ
consteval	84.74% <ø> (-15.26%)	⬇️
runtime	72.39% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jbcoe]

probe_key() calls INSTRUMENTED_HEADERS.index(probe_point.header) on every call. Storing the index on ProbePoint instead of just the header name would remove the repeated linear scan.

[jbcoe]

I'm struggling to decipher why arming multiple traps at once is valid. The speedup is impressive and makes sense but it's unclear to me (from reading code and comments) why we can arm multiple traps at the same time.

[philipcraig]

Two properties make it sound.

No false positives. A trap only throws when the evaluator executes it, and the diagnostic names the trap that threw. So every trap_hit<H, L> reported means line L of header H was evaluated, however many other traps were armed. Unarmed traps are if constexpr no-ops, so arming a set changes nothing but where evaluations abort.

No permanent false negatives. A throw aborts only its own top-level constant evaluation; GCC carries on with the rest of the translation unit and reports each failed evaluation separately. Within one evaluation, only the first armed trap on its path reports, and any armed trap after it is masked. The next round disarms everything found so far, so the evaluation now runs past that point and reports the next armed trap on its path. Any trap the test suite evaluates is preceded on its path only by traps the suite also evaluates, so by induction it is reported once those are disarmed. The armed set shrinks every productive round, so this terminates, and a round with no new hits means no remaining armed trap is on any evaluation path.

Cascading errors from an aborted evaluation (incomplete class, missing member) are not trap diagnostics, so they are ignored, and the evaluations they suppressed run in a later round once the trap is gone. A compile that fails with no trap firing raises instead.

Small illustration, three consteval functions with traps <0,10>, <1,20> then <1,21>, <1,21>, all armed: GCC reports <1,20> for the second function (its <1,21> is masked), <1,21> for the third, and <0,10> once per instantiation that calls the first. Disarming those three would surface the masked <1,21> in round two.

The one-compile-per-probe script and this one give the same 150/177, identical per header, which is the empirical check. cef9446 moves this explanation into the probe_translation_unit docstring, since that is where you looked for it.

[philipcraig]

ProbePoint now carries header_index and a key property, and probe_key() is gone: cef9446.

[jbcoe]

Thanks for this - a significant improvement.