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

undocumented_unsafe_blocks false positive when safety comment is on the previous line #8449

Closed
digama0 opened this issue Feb 19, 2022 · 1 comment · Fixed by #8450
Closed

Comments

@digama0
Copy link
Contributor

digama0 commented Feb 19, 2022

Description

This is somewhat annoying when the project uses minimal-scope unsafe blocks. I would prefer for the lint to only trigger if the previous line from the word unsafe is not part of a // Safety comment. Currently it requires that the comment directly precede the unsafe token, which leads to a false positive witth very awkward formatting in the suggestion.

#![warn(clippy::undocumented_unsafe_blocks)]

fn main() {
    let x = &0 as *const _;
    // Safety: x points to a valid value
    println!("{}", unsafe { *x })
}
warning: unsafe block missing a safety comment
 --> src/main.rs:6:19
  |
6 |     println!("{}", unsafe { *x })
  |                    ^^^^^^^^^^^^^
  |
note: the lint level is defined here
 --> src/main.rs:1:9
  |
1 | #![warn(clippy::undocumented_unsafe_blocks)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#undocumented_unsafe_blocks
help: consider adding a safety comment
  |
6 ~     println!("{}", // SAFETY: ...
7 ~     unsafe { *x })
  |

Version

rustc 1.60.0-nightly (b17226fcc 2022-02-18)
binary: rustc
commit-hash: b17226fcc11587fed612631be372a5b4cb89988a
commit-date: 2022-02-18
host: x86_64-unknown-linux-gnu
release: 1.60.0-nightly
LLVM version: 14.0.0

Additional Labels

No response

@digama0
Copy link
Contributor Author

digama0 commented Feb 19, 2022

If my reading of the code is correct, the reason for this behavior is here:

let enclosing_scope_span = map.opt_span(enclosing_hir_id)?;
let between_span = if block_span.from_expansion() {
self.macro_expansion = true;
enclosing_scope_span.with_hi(block_span.hi()).source_callsite()
} else {
self.macro_expansion = false;
enclosing_scope_span.to(block_span).source_callsite()
};

it only looks for comments in the enclosing scope. One way to fix this would be to keep going up the syntax tree until you find an enclosing scope that starts on a line different from the unsafe block itself. That would allow things like:

fn main() {
    // Safety: <- too far away to count
    { // <- this is the enclosing scope within which safety comments are permitted
        // Safety: <- safety comment permitted here 
        let x = { unsafe { foo() } }; // <- surrounding block scope is ignored because it starts on same line
    }
}

digama0 added a commit to digama0/mm0 that referenced this issue Feb 20, 2022
In principle this can be checked by the
clippy::undocumented_unsafe_blocks lint, and I used the lint to find
the issues. In practice the lint is buggy and so cannot safely be
enabled in CI. Hopefully it will be fixed within a few stable version
releases; keep your eyes on
rust-lang/rust-clippy#8449 .
@bors bors closed this as completed in 190f0de Apr 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant