From 2079411f4fcd0ec3e7dbc52f0a9cba4e8560dc3b Mon Sep 17 00:00:00 2001 From: enricobuehler Date: Sun, 9 Aug 2026 01:43:54 +0200 Subject: [PATCH] =?UTF-8?q?fix(pf-encode):=20the=20Windows=20host=20could?= =?UTF-8?q?=20not=20compile=20=E2=80=94=20a=20Linux-only=20reader=20trippe?= =?UTF-8?q?d=20dead=5Fcode?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The v0.26.0 tag went red on windows-host at the clippy step, after a clean build: error: function `wire_sequence` is never used --> crates\pf-encode\src\enc\pyrowave_wire.rs:68:15 = note: `-D dead-code` implied by `-D warnings` `pyrowave_wire` is cfg'd for linux OR windows and is genuinely shared — `packet_boundary` and `stamp_color_bits` each have callers on both backends. `wire_sequence` does not: every call site is in `enc/linux/pyrowave.rs`, which is `#[cfg(all(target_os = "linux", feature = "pyrowave"))]`. Alternating encoder handles are a Linux-side concern (PW5); the Windows backend drives pyrowave's compat device with a single handle and never needs the counter. The module's own `#[cfg(test)]` block does not reference it either, so on Windows the item has zero callers in every target and dead_code is correct — it is the `-D warnings` promotion to a hard error that stops the lib compiling. Scoped to the one item rather than the file, and expressed as `cfg_attr(not(target_os = "linux"), ...)` rather than a bare `allow`, so dead_code stays LIVE on Linux — where the caller lives, and where this function quietly losing its last caller would be a real finding rather than noise. ⚠ Not reproducible off a Windows box: cross-compiling to x86_64-pc-windows-msvc from macOS dies in openh264-sys2's build script (clang++ rejects `-fPIC` for that target) long before the lint stage. The mechanism is nonetheless exact — one item, one cfg, zero callers behind it — and the windows-host and windows-msix legs are the proof. No behaviour change on any platform: this adds a lint attribute and eight lines of comment. --- crates/pf-encode/src/enc/pyrowave_wire.rs | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/crates/pf-encode/src/enc/pyrowave_wire.rs b/crates/pf-encode/src/enc/pyrowave_wire.rs index 6ac4691d..00752ca5 100644 --- a/crates/pf-encode/src/enc/pyrowave_wire.rs +++ b/crates/pf-encode/src/enc/pyrowave_wire.rs @@ -65,6 +65,14 @@ pub(crate) fn stamp_color_bits(bitstream: &mut [u8], seq_offset: usize, bt2020_p /// repeated value is read as more blocks of the same frame. That is why PW5's alternating encoder /// handles need `pyrowave_encoder_set_next_sequence`, and why a test asserts this reader sees /// +1 mod 8 across the pair. +/// +/// Its only caller is the Linux backend — alternating encoder handles are a Linux-side concern, and +/// the Windows backend drives pyrowave's compat device with a single handle. The rest of this module +/// really is shared (`packet_boundary` and `stamp_color_bits` have callers on both), so the exemption +/// is scoped to this one item rather than the file: `dead_code` stays live on Linux, where the caller +/// lives and where its disappearing would be a real finding. Windows builds with `-D warnings`, so +/// without this the host and tray clippy legs fail to compile the lib at all. +#[cfg_attr(not(target_os = "linux"), allow(dead_code))] pub(crate) fn wire_sequence(bitstream: &[u8], packet_offset: usize) -> Option { let lo = *bitstream.get(packet_offset + 2)?; let hi = *bitstream.get(packet_offset + 3)?;