Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clippy treats /**…*/ doc comments differently from ///… doc comments #10277

Closed
jbr opened this issue Feb 2, 2023 · 2 comments · Fixed by rust-lang/rust#115689
Closed
Labels
C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have

Comments

@jbr
Copy link

jbr commented Feb 2, 2023

Summary

I had what seemed like a spurious clippy::missing_errors_doc that was resolved by changing /**… */ style doc comment into a ///… style doc comment. When I did that, additional clippy lints that were previously silent were revealed

Reproducer

playground link I would have expected the two functions to lint identically, but clippy's missing_errors_doc does not identify the # Errors section in one of them. This is not specific to missing_errors_doc but seems to apply to lint based on the content of the doc comment. Most of them are false negatives when using /**…*/, and as such are silent, but missing_errors_doc is a doc-comment-contents-based false-positive lint.

I would happily contribute a fix with guidance. On initial investigation, maybe this is the relevant line?

Thanks!

Version

rustc 1.69.0-nightly (c8e6a9e8b 2023-01-23)
binary: rustc
commit-hash: c8e6a9e8b6251bbc8276cb78cabe1998deecbed7
commit-date: 2023-01-23
host: x86_64-apple-darwin
release: 1.69.0-nightly
LLVM version: 15.0.7

Additional Labels

No response

@jbr jbr added the C-bug Category: Clippy is not doing the correct thing label Feb 2, 2023
@Alexendoo
Copy link
Member

Alexendoo commented Feb 2, 2023

They do have different representations, ctrl + f for # Errors in the output pane here https://godbolt.org/z/vee1zxbcr

I think you're in the right place yeah, my guess is the issue is here

if !contains_initial_stars {
return (doc.to_string(), sizes);
}

By playing with rustdoc a bit it looks we should be stripping an amount of whitespace equal to the least indented line in the block comment

@Alexendoo Alexendoo added the I-false-positive Issue: The lint was triggered on code it shouldn't have label Feb 2, 2023
@blyxyas
Copy link
Member

blyxyas commented May 14, 2023

@rustbot claim

@blyxyas blyxyas removed their assignment Aug 19, 2023
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Sep 12, 2023
…nishearth,flip1995

Reuse rustdoc's doc comment handling in Clippy

Moves `source_span_for_markdown_range` and `span_of_attrs` (renamed to `span_of_fragments`) to `rustc_resolve::rustdoc` so it can be used in Clippy

Fixes rust-lang/rust-clippy#10277
Fixes rust-lang/rust-clippy#5593
Fixes rust-lang/rust-clippy#10263
Fixes rust-lang/rust-clippy#2581
flip1995 pushed a commit to flip1995/rust-clippy that referenced this issue Sep 25, 2023
…nishearth,flip1995

Reuse rustdoc's doc comment handling in Clippy

Moves `source_span_for_markdown_range` and `span_of_attrs` (renamed to `span_of_fragments`) to `rustc_resolve::rustdoc` so it can be used in Clippy

Fixes rust-lang#10277
Fixes rust-lang#5593
Fixes rust-lang#10263
Fixes rust-lang#2581
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have
Projects
None yet
3 participants