From cf277b48283883c34e5565d2dec9c64fc721cb64 Mon Sep 17 00:00:00 2001 From: David Charlot Date: Mon, 21 Sep 2026 13:47:40 -0400 Subject: [PATCH] ci(standards-build): exercise the macOS energy backend, which nothing did MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `jcp-energy`'s IOReport meter — the Apple Silicon rung of the energy ladder — is behind `#[cfg(target_os = "macos")]`, and `jcp-rs` is pinned to the linux runner. A platform-gated test plus a single-platform runner assignment is **zero** coverage, and it is indistinguishable from passing: the code compiles out, the suite reports green, and nothing has been measured. Same family as a feature-gated test run with no `--features`, with `target_os` as the gate. Not hypothetical. On 2026-09-19 the counter read 0 µJ across a full run on the dev Mac — `IoReport::open()` succeeding while `read_uj()` returned nothing — and by 2026-09-21 it had healed with **no code change in between** (`git log --since=2026-09-17 -- crates/jcp-energy/` is empty; 8 of 8 runs now pass). Both observations came from a human running the suite by hand. CI saw neither, and could not have. That transience is the argument for the job rather than against it. A permanently dead counter gets noticed once and then known. One that reads zero for a while and silently recovers means `Meter::detect()` can, during such a window, select a backend measuring nothing in preference to the time×power rung below it — and then it heals, so anyone investigating afterwards finds a working counter and concludes there was never a problem. A human spot-check is worst precisely at catching that; a job that runs on every change is the instrument for it. Deliberately narrow: `-p jcp-energy --lib` only. `jcp-rs` stays on linux, so this **adds** the missing platform rather than trading one for the other, and costs one small crate instead of a second full workspace run. Every `cfg(target_os = "macos")` block in the crate lives in its lib tests, so `--lib` reaches all of them: 8 tests, 3 of them the IOReport ones. Verified to catch the real symptom, not merely to pass: forcing `read_uj()` to return `Some(0)` makes `cumulative_advances_after_cpu_burn` fail with `energy must advance: before=0 after=0` — byte-identical to the 2026-09-19 observation. Probe reverted and the revert checked with `git status`. This does **not** change energy-metering semantics. `Meter::detect()` still has no liveness probe, so it will still prefer a zero-reading IOReport backend over the rung below it; deciding what detect() should do when a counter reads zero is a semantic change to the ladder and is left alone deliberately. This commit only makes the condition visible. Co-Authored-By: Claude Opus 5 --- .github/workflows/standards-build.yml | 57 +++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/.github/workflows/standards-build.yml b/.github/workflows/standards-build.yml index e61c899b1..6e14d7353 100644 --- a/.github/workflows/standards-build.yml +++ b/.github/workflows/standards-build.yml @@ -197,3 +197,60 @@ jobs: env: RUSTFLAGS: ${{ matrix.rustflags }} run: cargo run -q -p ${{ matrix.conformance }} --bin ${{ matrix.conformance }} + + # ── The macOS energy backend is exercised NOWHERE otherwise ─────────────── + # + # `jcp-energy`'s IOReport meter — the Apple Silicon rung of the energy + # ladder — is behind `#[cfg(target_os = "macos")]`, and `jcp-rs` is pinned to + # the linux runner above. A platform-gated test plus a single-platform runner + # assignment is zero coverage, and it is indistinguishable from passing: the + # code compiles out, the suite reports green, and nothing has been measured. + # Same family as a feature-gated test with no `--features`, with `target_os` + # as the gate. + # + # This is not hypothetical. On 2026-09-19 the counter read 0 µJ across a full + # run on the dev Mac — `IoReport::open()` succeeding while `read_uj()` + # returned nothing — and by 2026-09-21 it had healed with no code change in + # between. Both observations came from a human running the suite by hand; + # CI saw neither. A meter that silently reads zero and later recovers is + # exactly the failure a human spot-check is worst at catching. + # + # Deliberately narrow: `-p jcp-energy` only. `jcp-rs` stays on linux, so this + # ADDS the platform that was missing rather than trading one for the other, + # and it costs one small crate rather than a second full workspace run. + # + # Verified to catch the real symptom: forcing `read_uj()` to return `Some(0)` + # makes `cumulative_advances_after_cpu_burn` fail with + # `energy must advance: before=0 after=0` — byte-identical to what was + # observed on 2026-09-19. + macos-energy-backend: + name: macOS energy backend (jcp-energy) + runs-on: macos + steps: + - uses: actions/checkout@v4 + + - name: Install Rust (workspace pin) + shell: bash + run: | + export PATH="$HOME/.cargo/bin:$PATH" + command -v rustup >/dev/null 2>&1 || \ + curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --profile minimal + echo "$HOME/.cargo/bin" >> "$GITHUB_PATH" + + - name: Cache cargo registry + target + uses: actions/cache@v4 + with: + path: | + ~/.cargo/registry + ~/.cargo/git + jcp/jcp-rs/target + key: standards-jcp-energy-macos-${{ hashFiles('jcp/jcp-rs/Cargo.lock', 'rust-toolchain.toml') }} + restore-keys: | + standards-jcp-energy-macos- + + # `--lib` keeps this to the crate's own tests, which is where every + # `cfg(target_os = "macos")` block in this crate lives. + - name: Energy backend tests (the cfg(macos) blocks) + working-directory: jcp/jcp-rs + run: cargo test --lib -p jcp-energy + -- 2.54.0 (Apple Git-157)