meters: clippy-clean in every Linux configuration, and a CI gate for it #650

Merged

dcharlot merged 6 commits from meters/clippy-clean into main 2026-11-06 02:39:54 -05:00

Conversation 0 Commits 6 Files changed 11 +87 -31

2026-11-05

Transaction Science

ci: lint the meter crates' Linux configurations, and the L3 example ...

The macOS lint step lints jcp-energy, eoc-meter, sandbox-meter and
jouleclaw-energy only as macOS builds them. The matrix's clippy gate is opt-in
per workspace, and none of these workspaces has it. So their Linux code (RAPL
through powercap and the MSRs, NVML, CUDA) was linted by no job.
jouleclaw-energy's `rapl` build carried a dead function, and four crates' NVML
hardware tests a clippy error, for as long as they existed.

- standards-build.yml: a matrix key `meter_lint` lists configurations
  (`package` or `package:features`), and a step "clippy on the Linux meter
  code" lints each one with `--all-targets --no-deps -D warnings` on the
  workspace's own runner, beside the feature-gated energy tests. The entries:
  - jcp-rs: jcp-energy, jcp-energy:nvml
  - eoc-rs: eoc-meter, eoc-meter:cuda
  - sandbox-rs: sandbox-meter
  - jouleclaw-rs: jouleclaw-energy, and with rapl, nvml and rapl,nvml
  scripts/standards-touched.py reads the new key like the others.
- joule-code-conformance.yml: "L3 JouleClaw binding example lints clean"
  (`--no-deps`), after its tests.

The step's loop was run verbatim on Linux x86_64 for each entry: all clean.
Both workflows parse, and the workflow-concurrency check passes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

48412b8df4

• View at this point in history

2026-11-05 10:21:57 -05:00

Transaction Science

Joule Code L3 example: clippy-clean ...

- src/llama_backend.rs: `rsplit(|c: char| c == '/' || c == ' ')` is now
  `rsplit(['/', ' '])` (manual_char_comparison); it splits the same way.
- src/bin/run.rs: the host test's catch-all arm asserted
  `!cfg!(macOS on aarch64)`, a constant assertion (assertions_on_constants).
  It is now an `if cfg!(...)` that panics with the same message.
- tests/common/mod.rs: each test binary compiles the shared module on its own,
  and the seeded test calls no `resolve_priced_at`. It gets the per-item
  `#[allow(dead_code)]` its sibling `resolve_seeded` already has, with the
  reason. `#[expect]` cannot work here: it would be unfulfilled in the
  binaries that do call it.

`cargo clippy --all-targets --no-deps -- -D warnings` is clean on Linux and
macOS, and the tests pass (16). The path dependencies' own rustc warnings
(jouleclaw-backend-apple, jouleclaw-topology, jouleclaw-backend-reference on
Linux) are not this crate's and are not denied by `--no-deps`.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

124b019b33

• View at this point in history

2026-11-05 10:21:57 -05:00

Transaction Science

sandbox-meter: the NVML hardware test's nvidia-smi triple is a type alias ...

tests/nvml_hardware.rs spelled `(Option<f64>, Option<f64>, Option<f64>)`
out three times, which clippy flags as type_complexity on Linux. It is now
the oracle's `SmiPower` alias. Clippy -D warnings is clean on Linux and in the
macOS lint step (sandbox-meter, sandbox-proof); Linux tests pass (166).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

c0bab66496

• View at this point in history

2026-11-05 10:21:44 -05:00

Transaction Science

eoc-meter: the NVML hardware test's nvidia-smi triple is a type alias ...

tests/nvml_hardware.rs spelled `(Option<f64>, Option<f64>, Option<f64>)`
out three times, which clippy flags as type_complexity under `--features
cuda`. It is now the oracle's `SmiPower` alias. Clippy -D warnings is clean on
Linux (default, cuda) and in the macOS lint step; Linux tests with cuda pass
(77).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

e8ac0fdfec

• View at this point in history

2026-11-05 10:21:44 -05:00

Transaction Science

jcp-energy: clippy-clean on Linux, with and without nvml ...

- `FabricMeter::readable` and `FabricMeter::measure` built their vector
  `mut` on every platform and pushed to it only on macOS, so Linux reported
  two unused `mut`s. Each now has a macOS body that builds and returns the
  vector, and a body for everywhere else that returns it empty. The behaviour
  is the same on both.
- `FabricSource::has_backend`: with `nvml` on, its match folded to a
  `matches!` (match_like_matches_macro). It is written as one, with the nvml
  arm still gated on the feature.
- tests/nvml_hardware.rs: the `nvidia-smi` power triple is the oracle's
  `SmiPower` alias (type_complexity under `--features nvml`).

Clippy -D warnings is clean on Linux (default, nvml) and in the macOS lint
step (jcp-energy, jcp-gateway). Tests pass: Linux default (68) and nvml (70),
macOS lib (128).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

fba729ce7b

• View at this point in history

2026-11-05 10:21:43 -05:00

Transaction Science

jouleclaw-energy: clippy-clean under rapl and nvml on Linux ...

- `--features rapl` alone: `liveness::probe` was never used. The RAPL probe
  reached the same code through `probe_packages_stepping(packages, || {})`,
  though rapl.rs documents its probe as `crate::liveness::probe`.
  `probe_packages` now calls `crate::liveness::probe` directly, which is the
  same call (probe = probe_stepping with a no-op step), and
  `probe_packages_stepping`, which only tests use, is `#[cfg(test)]`.
- `--features nvml`: tests/nvml_hardware.rs spelled an `nvidia-smi` power
  triple out three times (type_complexity). It is now the oracle's
  `SmiPower` alias.

Clippy -D warnings is clean on Linux (default, rapl, nvml, rapl+nvml) and
macOS (default, ioreport, smc, ioreport+smc, rapl). Tests pass: Linux rapl
(89) and rapl+nvml (96), macOS rapl lib (95).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1f9df46079

• View at this point in history

2026-11-05 10:21:43 -05:00