From 7f82bca9c0bf019d7b530af6e546cb42c889c0d1 Mon Sep 17 00:00:00 2001 From: enricobuehler Date: Sat, 8 Aug 2026 01:25:59 +0200 Subject: [PATCH] fix(pf-dxvadec): a wrapped sentence turned "6." into an ordered list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A doc paragraph in `pic_av1.rs` wrapped so that "first at frame / 6. Releasing…" put `6.` at the start of a line. rustdoc reads that as an ordered-list item starting at 6, which makes the following unindented `///` line a lazy continuation — `clippy::doc_lazy_continuation`, denied by `-D warnings`. Reflowed so the number cannot begin a line. Prose is byte-identical in content; only the wrap points move. No code, no behaviour. WHY THIS MATTERS FOR THE TAG. `pf-dxvadec` is Windows-only, and no Windows leg runs on a push to main — so main being green proves nothing about this. The failure surfaces for the first time in a release tag's fan-out, which is exactly what happened to the FIRST v0.23.0 tag: it went red on Windows clippy for this same lint, and the cure was a tag re-point. Caught pre-tag by re-running the lazy-continuation scanner over the tree while preparing v0.25.0 (0 hits before this commit's parent merged the new decode crates, 1 after). Cannot be verified by compiling here — the crate does not build on macOS — so the evidence is the scanner plus the lint's own rule, not a clippy run. --- crates/pf-dxvadec/src/pic_av1.rs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/crates/pf-dxvadec/src/pic_av1.rs b/crates/pf-dxvadec/src/pic_av1.rs index 4446ecc8..08af1dd3 100644 --- a/crates/pf-dxvadec/src/pic_av1.rs +++ b/crates/pf-dxvadec/src/pic_av1.rs @@ -129,10 +129,10 @@ pub struct DecodePlanDxvaAv1 { /// AV1 applies `refresh_frame_flags` AFTER the frame is decoded (7.20), so /// `ref_frame_idx` resolves against the store as it stood BEFORE this frame and /// a frame that reads a slot it then overwrites is the ORDINARY case, not an - /// exotic one: **268 of the vendored vector's 274 frames** do it, first at frame - /// 6. Releasing such a picture inside this conversion — which is what the H.264 - /// and H.265 siblings do with their whole `removed` list, and what this one did - /// until the parity harness caught it — hands its surface straight back to + /// exotic one: **268 of the vendored vector's 274 frames** do it, first at + /// frame 6. Releasing such a picture inside this conversion — which is what the + /// H.264 and H.265 siblings do with their whole `removed` list, and what this + /// one did until the parity harness caught it — hands its surface straight back to /// [`Self::setup_slot`], because [`SlotMap::assign`] takes the lowest free slot /// and the lowest free slot is the one just vacated. The submission then says /// `CurrPicTextureIndex = N` and `RefFrameMapTextureIndex[k] = N` in the same