The driver clippy gate has been red on main since the Xbox pad landed #150

Merged

enricobuehler merged 1 commits from worktree-drivers-clippy into main 2026-08-09 21:55:44 +00:00

Conversation 0 Commits 1 Files Changed 1

+5 -5

enricobuehler commented 2026-08-09 21:54:27 +00:00

Owner

Copy Link

Copy Source

windows-drivers → cargo clippy the shipped drivers (-D warnings — enforces the unsafe-audit gates) fails on main as of 5d7091bf (the #149 merge). This is a main-branch breakage, not a PR canary.

What broke

Clippy 1.96 added manual_range_patterns. #149 introduced three Xbox identities — 4 Wireless, 5 One S, 6 Elite Series 2 — matched as 4 | 5 | 6 in five places in pf-gamepad/src/lib.rs. Under -D warnings each becomes an error:

error: this OR pattern can be rewritten using a range
   --> pf-gamepad\src\lib.rs:583:9
    |
583 |         4 | 5 | 6 => XBOX_INPUT_REPORT_LEN,
    |         ^^^^^^^^^ help: try: `4..=6`

×5, so pf-gamepad fails to compile as both lib and lib-test, and the step dies before the other five crates are ever linted — including pf-xusb, which #149 also changed (+86 lines).

The fix

The five arms become 4..=6. The device types are contiguous by construction, so it is the same set: no arm gains or loses a device type. The comments that already record why the three identities share one report shape, one descriptor and one vendor string are untouched, and the file's bare-literal style (1 DS4, 2 Edge, 3 Deck) is preserved rather than introducing named constants for Xbox alone.

5 insertions, 5 deletions, one file. No behaviour change.

Verification

Ran the exact CI command on the windows-amd64 runner, full tree, fresh directory so no stale artifact could produce a vacuous green:

cargo clippy -p pf-umdf-util -p pf-xusb -p pf-gamepad -p pf-mouse -p wdk-iddcx -p pf-vdisplay --all-targets -- -D warnings
→ CLIPPY_RC=0    (cold build, 1m09s, zero warning/error lines)

• clippy 0.1.96 — the same version that produced the failure.
• Now that the run gets past pf-gamepad, the other five crates are confirmed clean too; that was previously unknown, since the aborted build never reported on them.
• rustfmt --edition 2024 --check clean on the edited file. The CI's cargo fmt -p … step was not runnable on the box (no rustfmt component under that CARGO_HOME), so that leg is verified via rustfmt directly rather than through cargo.

`windows-drivers` → **cargo clippy the shipped drivers (-D warnings — enforces the unsafe-audit gates)** fails on `main` as of `5d7091bf` (the #149 merge). This is a main-branch breakage, not a PR canary. ## What broke Clippy 1.96 added `manual_range_patterns`. #149 introduced three Xbox identities — `4` Wireless, `5` One S, `6` Elite Series 2 — matched as `4 | 5 | 6` in five places in `pf-gamepad/src/lib.rs`. Under `-D warnings` each becomes an error: ``` error: this OR pattern can be rewritten using a range --> pf-gamepad\src\lib.rs:583:9 | 583 | 4 | 5 | 6 => XBOX_INPUT_REPORT_LEN, | ^^^^^^^^^ help: try: `4..=6` ``` ×5, so `pf-gamepad` fails to compile as both lib and lib-test, and **the step dies before the other five crates are ever linted** — including `pf-xusb`, which #149 also changed (+86 lines). ## The fix The five arms become `4..=6`. The device types are contiguous by construction, so it is the same set: no arm gains or loses a device type. The comments that already record *why* the three identities share one report shape, one descriptor and one vendor string are untouched, and the file's bare-literal style (`1` DS4, `2` Edge, `3` Deck) is preserved rather than introducing named constants for Xbox alone. 5 insertions, 5 deletions, one file. No behaviour change. ## Verification Ran the **exact CI command** on the `windows-amd64` runner, full tree, fresh directory so no stale artifact could produce a vacuous green: ``` cargo clippy -p pf-umdf-util -p pf-xusb -p pf-gamepad -p pf-mouse -p wdk-iddcx -p pf-vdisplay --all-targets -- -D warnings → CLIPPY_RC=0 (cold build, 1m09s, zero warning/error lines) ``` - clippy **0.1.96** — the same version that produced the failure. - Now that the run gets past `pf-gamepad`, the other five crates are confirmed clean too; that was previously unknown, since the aborted build never reported on them. - `rustfmt --edition 2024 --check` clean on the edited file. The CI's `cargo fmt -p …` step was not runnable on the box (no `rustfmt` component under that `CARGO_HOME`), so that leg is verified via `rustfmt` directly rather than through cargo.

enricobuehler added 1 commit 2026-08-09 21:54:28 +00:00

fix(drivers/pf-gamepad): the three Xbox identities as a range — the driver clippy gate is red on main ... c7df7b45af

`cargo clippy --all-targets -- -D warnings` over the shipped drivers (the step that
enforces the unsafe-audit gates) fails on main since #149 landed: clippy 1.96's
`manual_range_patterns` fires on all five `4 | 5 | 6` device-type arms, and `-D warnings`
turns each into an error, so `pf-gamepad` fails to compile as both lib and lib-test and
the whole step never reaches the other five crates.

Device types 4/5/6 are the Xbox Wireless / One S / Elite Series 2 identities added by
#149 — contiguous by construction, so `4..=6` is the same set. Purely a lint fix: no arm
gains or loses a device type, and the comments that already record *why* the three share
one report shape, one descriptor and one vendor string are untouched.

enricobuehler merged commit 73d435b967 into main 2026-08-09 21:55:44 +00:00

enricobuehler deleted branch worktree-drivers-clippy 2026-08-09 21:55:46 +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#150