-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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 positives around attributes
#13189
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
27 tasks
ojeda
changed the title
Jul 30, 2024
undocumented_unsafe_blocks
false positivesundocumented_unsafe_blocks
false positives around attributes
Not sure if I can do this, but: @rustbot label +C-bug +I-false-negative |
rustbot
added
C-bug
Category: Clippy is not doing the correct thing
I-false-negative
Issue: The lint should have been triggered on code, but wasn't
labels
Aug 4, 2024
Sorry, the main case is (I assume) a false positive (and likely all of the ones listed above): @rustbot label -I-false-negative +I-false-positive |
rustbot
added
I-false-positive
Issue: The lint was triggered on code it shouldn't have
and removed
I-false-negative
Issue: The lint should have been triggered on code, but wasn't
labels
Aug 4, 2024
ojeda
added a commit
to ojeda/linux
that referenced
this issue
Sep 3, 2024
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
ojeda
added a commit
to ojeda/linux
that referenced
this issue
Sep 4, 2024
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
ojeda
added a commit
to ojeda/linux
that referenced
this issue
Oct 3, 2024
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
ojeda
added a commit
to Rust-for-Linux/linux
that referenced
this issue
Oct 7, 2024
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: #351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
ojeda
added a commit
to Rust-for-Linux/linux
that referenced
this issue
Oct 7, 2024
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: #351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
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
Assuming the most relaxed setup, i.e. the defaults (
accept-comment-above-attribute = true
andaccept-comment-above-statement = true
),undocumented_unsafe_blocks
seems to have false positives around attributes, since moving the attribute on top makes it work (i.e. it does not lint anymore) in all cases.For instance, we had this code:
Is this expected to trigger? It currently lints. Perhaps the developer is expected to put the
// SAFETY
comment insideErr
:That works (i.e. it does not lint anymore), although it may be debatable whether it looks/is better or not.
However, moving the attribute on top of the comment also makes it work (i.e. it does not lint anymore):
which is a bit surprising. It seems like that is "close enough". Should that trigger, or not?
Moreover, testing a few more variations, I found that this would also lint:
For this one, moving the comment below the attribute makes it pass too.
Below I leave a few more variations/test cases. Which ones should pass, or not? Given that all of them pass when the comment is moved below the attribute, it would seem that all of them were expected to pass (i.e. not lint).
The text was updated successfully, but these errors were encountered: