rustdoc: do not include extra stuff in span

[notriddle]

View all comments

This change prevents our lints from returning a span with stuff in it that isn't actually part of the doc comment. When that happens, it returns None instead.

Fixes rust-lang/rust-clippy#16169, since the bug was reported against the clippy::doc_paragraphs_missing_punctuation lint but is actually a bug in source_span_for_markdown_range_inner.

[rustbot]

r? @lolbinarycat

rustbot has assigned @lolbinarycat.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: rustdoc
• rustdoc expanded to 9 candidates
• Random selection from GuillaumeGomez, camelid, lolbinarycat

[notriddle]

p.s. this change is a lot easier to understand if you use the hide whitespace setting on the diff.

[rustbot]

The Clippy subtree was changed

cc @rust-lang/clippy

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[lolbinarycat]

Do we need to be optimizing our diagnostic code (cold path) to the extent of using binary search to find an item in a usually small list? this only speeds up doc generation if a crate has a ton of warnings. I guess I'll see if it shows up at all in a perf run.

@bors try @rust-timer queue profiles=doc

[rust-bors]

☀️ Try build successful (CI)
Build commit: a64b630 (a64b630f04e7c6ae84c88850e738cae44ce235d7, parent: 65407954098ca3c19f0d46092cb374b5d3e9dc3c)

[rust-timer]

Finished benchmarking commit (a64b630): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

This perf run didn't have relevant results for this metric.

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 518.069s -> 524.961s (1.33%)
Artifact size: 401.35 MiB -> 401.38 MiB (0.01%)

[notriddle]

Do we need to be optimizing our diagnostic code (cold path) to the extent of using binary search to find an item in a usually small list?

I knew it would be O(n²) if just did a linear scan. Even in the cold path, I'd prefer to avoid that.

[lolbinarycat]

I don't think algorimic complexity is really relevant here.

[notriddle]

@bors try @rust-timer queue profiles=doc

[rust-bors]

☀️ Try build successful (CI)
Build commit: 1a5fffe (1a5fffe9955796b4c20810d806e19fca4d8f6e34, parent: e7ef22d23f10e9e05546592aa9c1e3e8bb288969)

[rust-timer]

Finished benchmarking commit (1a5fffe): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

This perf run didn't have relevant results for this metric.

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 521.088s -> 525.76s (0.90%)
Artifact size: 401.44 MiB -> 401.46 MiB (0.00%)

[notriddle]

Here's the new non-relevant result set: