fix(pf-dxvadec): a wrapped sentence turned "6." into an ordered list #104

Merged

enricobuehler merged 1 commits from worktree-dxva-doclint into main 2026-08-07 23:26:57 +00:00

Conversation 0 Commits 1 Files Changed 1

+4 -4

enricobuehler commented 2026-08-07 23:26:21 +00:00

Owner

Copy Link

Copy Source

Merge before tagging v0.25.0. One doc-comment reflow; no code, no behaviour.

A 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.

-    /// 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
+    /// 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

Prose is unchanged in content; only the wrap points move so the number cannot begin a line.

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 says nothing about it. This surfaces for the first time during a release tag's fan-out.

That is not hypothetical: the first v0.23.0 tag went red on Windows clippy for this exact lint, and the cure was a tag re-point. The pre-tag scanner exists because of that incident, and it caught this one while I was preparing v0.25.0 — 0 hits before the parent merge brought in the new decode crates, 1 hit after.

Verification

Scanner clean (0 hits over 582 files) and cargo fmt --all --check clean. ⚠️ Not verified by a clippy run — the crate does not build on macOS, so the evidence is the scanner plus the lint's own rule. The Windows leg on this PR is the real check.

**Merge before tagging v0.25.0.** One doc-comment reflow; no code, no behaviour. A 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`. ``` - /// 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 + /// 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 ``` Prose is unchanged in content; only the wrap points move so the number cannot begin a line. ## 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 says nothing about it. This surfaces for the first time during a release tag's fan-out. That is not hypothetical: **the first `v0.23.0` tag went red on Windows clippy for this exact lint**, and the cure was a tag re-point. The pre-tag scanner exists because of that incident, and it caught this one while I was preparing v0.25.0 — 0 hits before the parent merge brought in the new decode crates, 1 hit after. ## Verification Scanner clean (0 hits over 582 files) and `cargo fmt --all --check` clean. ⚠️ **Not verified by a clippy run** — the crate does not build on macOS, so the evidence is the scanner plus the lint's own rule. The Windows leg on this PR is the real check.

enricobuehler added 1 commit 2026-08-07 23:26:24 +00:00

fix(pf-dxvadec): a wrapped sentence turned "6." into an ordered list ... 7f82bca9c0

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.

enricobuehler merged commit b2f08b1a73 into main 2026-08-07 23:26:57 +00:00

enricobuehler deleted branch worktree-dxva-doclint 2026-08-07 23:27:08 +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#104