Summary
filter_map::decode_provider_data has no test at all. It was rewritten in PR #18 (commit 3de3c10)
to satisfy clippy 1.98's chunks_exact_to_as_chunks, and the correctness of that rewrite rests
entirely on the two expressions happening to be equivalent — nothing in the repo pins it.
Where
src/filter_map.rs:151 — decode_provider_data, #[cfg(windows)].scripts/gate.sh — the Windows leg runs cargo clippy --target x86_64-pc-windows-gnu without
--all-targets, so Windows-only test code is not linted. The native leg uses --all-targets.
Detail
The change was .chunks_exact(2).map(|c| u16::from_le_bytes([c[0], c[1]])) →
.as_chunks::<2>().0.iter().map(|c| u16::from_le_bytes(*c)).
Two independent agents checked equivalence differentially before the merge — one over lengths 0..64
plus 2000 random blobs, one over lengths 0..40 — and both found the outputs identical, including the
trailing-odd-byte case that chunks_exact drops and as_chunks puts in .1. That is good evidence
and it is not a test. Nothing stops the next edit here.
The function is also unreachable from any test host: it is #[cfg(windows)], so it compiles under
the cross-compile leg but is never executed anywhere in CI.
Fix
Add an inline test for decode_provider_data under #[cfg(any(windows, test))] — the convention
CLAUDE.md already states for portable logic called from one platform only — covering an empty
slice, a 1-byte slice, an odd-length blob, embedded control characters (which the function strips),
and the 256-byte cap on the hex dump.
Separately, decide whether the Windows clippy leg should gain --all-targets so Windows-only test
code is linted at all. It currently is not, which is why this gap was invisible.
Status: Suspected
No defect observed. The risk is the absence of a guard, not a known wrong answer.
Severity: Low · Suspected · from the PR #18 run record,
factory/runs/20260906-112236-bridge-totals-flake.json
Summary
filter_map::decode_provider_datahas no test at all. It was rewritten in PR #18 (commit3de3c10)to satisfy clippy 1.98's
chunks_exact_to_as_chunks, and the correctness of that rewrite restsentirely on the two expressions happening to be equivalent — nothing in the repo pins it.
Where
src/filter_map.rs:151—decode_provider_data,#[cfg(windows)].scripts/gate.sh— the Windows leg runscargo clippy --target x86_64-pc-windows-gnuwithout--all-targets, so Windows-only test code is not linted. The native leg uses--all-targets.Detail
The change was
.chunks_exact(2).map(|c| u16::from_le_bytes([c[0], c[1]]))→.as_chunks::<2>().0.iter().map(|c| u16::from_le_bytes(*c)).Two independent agents checked equivalence differentially before the merge — one over lengths 0..64
plus 2000 random blobs, one over lengths 0..40 — and both found the outputs identical, including the
trailing-odd-byte case that
chunks_exactdrops andas_chunksputs in.1. That is good evidenceand it is not a test. Nothing stops the next edit here.
The function is also unreachable from any test host: it is
#[cfg(windows)], so it compiles underthe cross-compile leg but is never executed anywhere in CI.
Fix
Add an inline test for
decode_provider_dataunder#[cfg(any(windows, test))]— the conventionCLAUDE.mdalready states for portable logic called from one platform only — covering an emptyslice, a 1-byte slice, an odd-length blob, embedded control characters (which the function strips),
and the 256-byte cap on the hex dump.
Separately, decide whether the Windows clippy leg should gain
--all-targetsso Windows-only testcode is linted at all. It currently is not, which is why this gap was invisible.
Status: Suspected
No defect observed. The risk is the absence of a guard, not a known wrong answer.
Severity: Low · Suspected · from the PR #18 run record,
factory/runs/20260906-112236-bridge-totals-flake.json