fix(host/encode): the Windows host build stops failing on unused split-encode helpers #86

Merged

enricobuehler merged 1 commits from worktree-fix-winhost-clippy-dead-code into main 2026-08-07 09:22:59 +00:00

Conversation 0 Commits 1 Files Changed 1

+25

enricobuehler commented 2026-08-07 09:21:25 +00:00

Owner

Copy Link

Copy Source

What was wrong

The Windows host job has been red on main — runs 16061 and 16074, both dying at the Clippy (host + tray, Windows) step with eight dead_code errors in crates/pf-encode/src/enc/codec.rs:

error: constant `SPLIT_AUTO` is never used
error: constant `SPLIT_AUTO_FORCED` is never used
error: constant `SPLIT_TWO_FORCED` is never used
error: constant `SPLIT_THREE_FORCED` is never used
error: constant `SPLIT_DISABLE` is never used
error: function `resolve_split_mode` is never used
error: function `max_forced_split_mode` is never used
error: function `clamp_to_engines` is never used
error: could not compile `pf-encode` (lib) due to 8 previous errors

Nothing about the encoder is broken. codec.rs compiles on every platform, but the split-encode policy only ever has a reader on Linux (the libav NVENC path in enc/linux/mod.rs calls resolve_split_mode unconditionally — the whole reason the policy lives in this featureless file) or on Windows with feature = "nvenc" (the direct-SDK backend in enc/windows/nvenc.rs). A featureless Windows build of pf-encode has neither, so the entire cluster is genuinely dead there.

Why it slipped through

dead_code is an item lint, so reasoning about the module's own cfg does not catch it — and the step's own shape hides it. The step lints pf-encode itself with --features nvenc,amf-qsv,qsv --all-targets, where every item is live and everything looks fine. The failure comes from the next command in the same step:

cargo clippy --release -p pf-vdisplay --all-targets -- -D warnings

pf-vdisplay takes pf-encode = { path = "../pf-encode" } — plain default features — for its NVENC session-budget admission gate. So a green -p pf-encode in that step proves nothing about this class of problem. (The thrown error names pf-vdisplay clippy, which is the real tell in the log.)

The fix

Gate the eight items on the union of their callers' cfgs:

#[cfg(any(target_os = "linux", all(target_os = "windows", feature = "nvenc")))]

This is the same idiom forced_split_width a few lines below already carries, and byte-for-byte the same windows+nvenc expression lib.rs:1958 already uses for the nvenc module. The diff is 25 added lines and nothing else — no configuration that previously compiled this code sees any change, and SPLIT_FORCE_PIXEL_RATE stays pub and ungated.

Deliberately not an #[allow(dead_code)]: the crate root carries an explicit note that the inherited crate-wide allow was removed because it hid exactly two items and blinded the crate to rot.

Verification

Found a much cheaper oracle than a Windows box — cargo clippy -p pf-encode -- -D warnings on macOS reproduces it in ~15 s. macOS default-features exercises the identical "this item has no caller" arm as featureless Windows, because both compile codec.rs while compiling neither nvenc backend. pf-encode is genuinely compiled there (cfg(not(any(linux, windows))) arms exist), not a vacuous pass.

Config	Before	After
macOS, default features (proxy for featureless Windows)	8 errors — exactly the CI set	0
Linux, default features (libav path is the caller)	clean	clean
Linux, --features nvenc --all-targets (direct-SDK + nvenc_core tests)	clean	clean
cargo fmt --check -p pf-encode	clean	clean

Two errors remain in the macOS run — vbv_frames_env never used, and a redundant_closure_call in host_wire_caps. Both are pre-existing and macOS-only, and out of scope here: vbv_frames_env has real callers in enc/windows/amf.rs (featureless on Windows) and enc/libav.rs, which is why CI never flagged it. Judge such a run by whether your items appear, not by exit code.

⚠️ scripts/xcheck.sh windows cannot cover any of this — it deliberately stubs pf-encode out, because the real crate drags in ffmpeg-sys, whose build script wants a Windows FFmpeg tree.

Notes

This is the sixth time this crate has hit the item-level dead_code trap (after subframe_env_forced, the nvenc_core arbiter items, forced_split_width, clear_split_verdicts, and arbiter methods landing in impl Encoder). The standing note said it was only catchable by running a Windows build; the macOS default-features clippy above shows that is not true, and it is the cheap gate to run before touching anything in codec.rs.

## What was wrong The Windows host job has been red on `main` — runs [16061](https://git.unom.io/unom/punktfunk/actions/runs/16061) and [16074](https://git.unom.io/unom/punktfunk/actions/runs/16074), both dying at the **Clippy (host + tray, Windows)** step with eight `dead_code` errors in `crates/pf-encode/src/enc/codec.rs`: ``` error: constant `SPLIT_AUTO` is never used error: constant `SPLIT_AUTO_FORCED` is never used error: constant `SPLIT_TWO_FORCED` is never used error: constant `SPLIT_THREE_FORCED` is never used error: constant `SPLIT_DISABLE` is never used error: function `resolve_split_mode` is never used error: function `max_forced_split_mode` is never used error: function `clamp_to_engines` is never used error: could not compile `pf-encode` (lib) due to 8 previous errors ``` Nothing about the encoder is broken. `codec.rs` compiles on every platform, but the split-encode policy only ever has a reader on **Linux** (the libav NVENC path in `enc/linux/mod.rs` calls `resolve_split_mode` unconditionally — the whole reason the policy lives in this featureless file) or on **Windows with `feature = "nvenc"`** (the direct-SDK backend in `enc/windows/nvenc.rs`). A featureless Windows build of `pf-encode` has neither, so the entire cluster is genuinely dead there. ## Why it slipped through `dead_code` is an **item** lint, so reasoning about the module's own cfg does not catch it — and the step's own shape hides it. The step lints `pf-encode` itself **with** `--features nvenc,amf-qsv,qsv --all-targets`, where every item is live and everything looks fine. The failure comes from the *next* command in the same step: ```pwsh cargo clippy --release -p pf-vdisplay --all-targets -- -D warnings ``` `pf-vdisplay` takes `pf-encode = { path = "../pf-encode" }` — plain default features — for its NVENC session-budget admission gate. So a green `-p pf-encode` in that step proves nothing about this class of problem. (The thrown error names `pf-vdisplay clippy`, which is the real tell in the log.) ## The fix Gate the eight items on the union of their callers' cfgs: ```rust #[cfg(any(target_os = "linux", all(target_os = "windows", feature = "nvenc")))] ``` This is the same idiom `forced_split_width` a few lines below already carries, and byte-for-byte the same windows+nvenc expression `lib.rs:1958` already uses for the `nvenc` module. The diff is **25 added lines and nothing else** — no configuration that previously compiled this code sees any change, and `SPLIT_FORCE_PIXEL_RATE` stays `pub` and ungated. Deliberately *not* an `#[allow(dead_code)]`: the crate root carries an explicit note that the inherited crate-wide allow was removed because it hid exactly two items and blinded the crate to rot. ## Verification Found a much cheaper oracle than a Windows box — **`cargo clippy -p pf-encode -- -D warnings` on macOS reproduces it in ~15 s**. macOS default-features exercises the identical "this item has no caller" arm as featureless Windows, because both compile `codec.rs` while compiling neither nvenc backend. `pf-encode` is genuinely compiled there (`cfg(not(any(linux, windows)))` arms exist), not a vacuous pass. | Config | Before | After | |---|---|---| | macOS, default features (proxy for featureless Windows) | **8 errors** — exactly the CI set | **0** | | Linux, default features (libav path is the caller) | clean | clean | | Linux, `--features nvenc --all-targets` (direct-SDK + `nvenc_core` tests) | clean | clean | | `cargo fmt --check -p pf-encode` | clean | clean | Two errors remain in the macOS run — `vbv_frames_env` never used, and a `redundant_closure_call` in `host_wire_caps`. Both are **pre-existing and macOS-only**, and out of scope here: `vbv_frames_env` has real callers in `enc/windows/amf.rs` (featureless on Windows) and `enc/libav.rs`, which is why CI never flagged it. Judge such a run by whether *your* items appear, not by exit code. ⚠️ `scripts/xcheck.sh windows` cannot cover any of this — it deliberately **stubs `pf-encode` out**, because the real crate drags in `ffmpeg-sys`, whose build script wants a Windows FFmpeg tree. ## Notes This is the **sixth** time this crate has hit the item-level `dead_code` trap (after `subframe_env_forced`, the `nvenc_core` arbiter items, `forced_split_width`, `clear_split_verdicts`, and arbiter methods landing in `impl Encoder`). The standing note said it was only catchable by running a Windows build; the macOS default-features clippy above shows that is not true, and it is the cheap gate to run before touching anything in `codec.rs`.

enricobuehler added 1 commit 2026-08-07 09:21:27 +00:00

fix(host/encode): the Windows host build stops failing on unused split-encode helpers ... f49f22a292

The Windows host job died in its clippy step: eight items in pf-encode's
split-encode policy (`SPLIT_AUTO`..`SPLIT_DISABLE`, `resolve_split_mode`,
`max_forced_split_mode`, `clamp_to_engines`) were reported as never used, and
`-D warnings` turns that into a build failure. Nothing about the encoder was
wrong — the items simply have no reader in one particular build of the crate,
and nothing was telling the compiler that.

`codec.rs` compiles on every platform, but the split policy only ever has a
caller on Linux (the libav NVENC path reads it unconditionally) or on Windows
with the `nvenc` feature (the direct-SDK backend). A featureless Windows build
of pf-encode has neither, so every item in the cluster is genuinely dead there.
Gate them on the union of their callers' cfgs, the way `forced_split_width`
next door already is.

The step lints pf-encode itself WITH `--features nvenc,amf-qsv,qsv`, where the
items are live, which is why this was invisible there; the failure came from the
next command in the same step, `clippy -p pf-vdisplay`, which pulls pf-encode in
as a plain default-features dependency. Same item-level `dead_code` trap this
crate has now hit five times.

Verified: default-features pf-encode reproduces all eight errors before the
change and none after (macOS default-features exercises the identical
"cluster has no caller" arm as featureless Windows — the two remaining errors
there, `vbv_frames_env` and a redundant closure call, are pre-existing and
macOS-only; both items have real Windows callers). Linux default-features and
Linux + nvenc `--all-targets` both stay clean, so the callers still see the
policy. `cargo fmt` clean.

enricobuehler merged commit 5aa1ca392e into main 2026-08-07 09:22:59 +00:00

enricobuehler deleted branch worktree-fix-winhost-clippy-dead-code 2026-08-07 09:23:06 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

FernandoMX enricobuehler (Enrico Bühler) kszlim nannku neoney sassycrown

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unom/punktfunk#86