👷 ci: gate coverage on lines nothing ran

[gaborbernat]

--fail-uncovered-lines 0 reads a narrower thing than its name suggests, so the workspace passes it while lines nothing executed sit behind a covered caller. This closes that gap, and it closes it against a number that means what the gate wants rather than against LLVM's own total.

LLVM's total is not the count of lines nothing ran. It sums a file's lines per function, and where a generic has several monomorphizations it scores their instantiation group by taking the mapped count and the covered count from whichever member is highest at each, on its own. A line one monomorphization runs and another does not then counts as missed while executing. On this workspace the total reported 88 lines and this check reports 22, so 66 of the 88 were reported missed while executing. Closing those would have meant changing which concrete type a test picks, which moves the count alone.

A reviewer can confirm that rather than take it. The old flags and the new check ran in the same job on the same profile data: the total said 271519 lines and 88 missed, and coverage_lines.py names 22 in 15 files. The classification behind the split came out of #2232, which read the per-function line stats out of the JSON export, grouped them by instantiation, and closed eighteen lines that were genuine gaps; this check is that method wired into the gate.

coverage_lines.py takes the union across a group: a line stays missed only when no member of its instantiation group ran it. That leaves the gate on unexecuted code and drops the merge artefact, so it measures the truth rather than loosening the bar. --fail-uncovered-lines 0 stays exactly as it was, because it is the half that finds real gaps: every line it named today was a genuine defect or a missing assertion, across #2213, #2187, #2195 and #2231. What it cannot see is a function body nothing ran whose lines a covered caller spans, and that is what the new check adds.

_coverage-lines-contract makes the behaviour checkable. It builds a two-file export where one file holds two monomorphizations of a generic, each running the line the other does not, and the second holds a body nothing ran, then asserts the first is forgiven and the second reported. Scoring the group by its best single member, the way LLVM's total does, makes that contract fail; so does reporting nothing at all.

Worth stating as the boundary of what any of this proves: passing a line gate does not mean a crate has no unreachable code. A line that ran can still hold an arm that never did. The pypi lane found page_stream/mod.rs:335, a size-limit guard that can never match, because stream_detail returns Fallback at line 125 before its only call to streaming_parts. Line coverage called it covered, since the guard and its Ok(None) body share one line and evaluating the guard marks the line executed. Mutation testing caught it when line coverage could not. Both facts follow from measuring lines rather than branches: one direction demands edits for lines that already execute, the other certifies lines whose dead arms it cannot see.

On this branch the gate named 14 lines in 10 files, and all 14 are closed here. Two were fallibility no run can reach, so they are gone rather than tested. plan already turns a second snapshot into RetentionPlanError::Store before the callback export_body installs is called again, which made the guard inside that callback a second copy of the same rule carrying the same message. serde_json::to_string over a Value cannot fail, so the retention CLI header takes the same non-fallible path as the decision writer beside it.

One was an assertion that could not fail: the oci admission test searched an empty capture for a warning, which passes whatever the push did, and it now compares the whole captured set against the key the push staged under. The other eleven are error arms with a fault driven through them. A truncated multipart body reaches the two field readers in upload_form.rs. Injection sweeps across the redb backend reach store/files.rs:140 and both filter scans in store/projects.rs, and a store whose policy generation row does not decode reaches the retention plan and the metadata rebuild in the peryx fixture driver. A replication token the leader answers 401 to reaches the forwarded ClientWrite in consensus_runtime.rs. A startup line carrying no port reaches the bench harness, and two fixture modes reach the second startup wait and the status probe in peryx-test-support.

store/files.rs:140 was listed above as resisting, because a redb handle does not survive its own injected failure and an Err cannot be told apart from a commit that landed and then failed its sync. That distinction turns out not to be the one worth making. The property is that the sweep leaves every legacy row or none, which holds at both ends of that range and rules out the half-swept store an operator reads as progress.

Closes #1745

[codspeed-hq]

Merging this PR will not alter performance

✅ 29 untouched benchmarks
⏩ 133 skipped benchmarks¹

---

_{Comparing fix/enforce-total-line-coverage-1745 (c4815b4) with main (34eca99)}

Footnotes

1. 133 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[read-the-docs-community]

Documentation build overview

📚 peryx | 🛠️ Build #34476592 | 📁 Comparing c4815b4 against latest (892226e)

  🔍 Preview build  

4 files changed

± contributing/ci/index.html
± core/repositories/artifact-source/index.html
± core/repositories/trash/index.html
± ecosystems/pypi/reference/changelog/index.html