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 positives around attributes #13189

Open
ojeda opened this issue Jul 30, 2024 · 2 comments
Open

undocumented_unsafe_blocks false positives around attributes #13189

ojeda opened this issue Jul 30, 2024 · 2 comments
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

@ojeda
Copy link
Contributor

ojeda commented Jul 30, 2024

Assuming the most relaxed setup, i.e. the defaults (accept-comment-above-attribute = true and accept-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:

    // SAFETY: ...
    #[allow(clippy::unnecessary_cast)]
    return Err(unsafe { Error::from_errno_unchecked(err as core::ffi::c_int) });

Is this expected to trigger? It currently lints. Perhaps the developer is expected to put the // SAFETY comment inside Err:

    return Err(
        // SAFETY: ...
        #[allow(clippy::unnecessary_cast)]
        unsafe { Error::from_errno_unchecked(err as core::ffi::c_int) }
    );

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):

    #[allow(clippy::unnecessary_cast)]
    // SAFETY: ...
    return Err(unsafe { Error::from_errno_unchecked(err as core::ffi::c_int) });

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:

    // SAFETY: ...
    #[allow(clippy::unnecessary_cast)]
    return unsafe { h() };

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

#![allow(clippy::needless_return)]
#![allow(clippy::let_and_return)]

extern {
    fn h() -> i32;
}

pub fn f1a() -> i32 {
    // SAFETY: OK.
    #[allow(clippy::unnecessary_cast)]
    unsafe { h() }
}

pub fn f1b() -> Result<i32, i32> {
    // SAFETY: Warns.
    #[allow(clippy::unnecessary_cast)]
    Ok(unsafe { h() })
}

pub fn f1c() -> Result<i32, i32> {
    Ok(
        // SAFETY: OK.
        #[allow(clippy::unnecessary_cast)]
        unsafe { h() }
    )
}

pub fn f2a() -> i32 {
    // SAFETY: Warns.
    #[allow(clippy::unnecessary_cast)]
    return unsafe { h() };
}

pub fn f2b() -> Result<i32, i32> {
    // SAFETY: Warns.
    #[allow(clippy::unnecessary_cast)]
    return Ok(unsafe { h() });
}


pub fn f2c() -> Result<i32, i32> {
    return Ok(
        // SAFETY: OK.
        #[allow(clippy::unnecessary_cast)]
        unsafe { h() }
    );
}


pub fn f3a() -> i32 {
    // SAFETY: OK.
    #[allow(clippy::unnecessary_cast)]
    let x = unsafe { h() };

    x
}

pub fn f3b() -> Result<i32, i32> {
    // SAFETY: Warns.
    #[allow(clippy::unnecessary_cast)]
    let x = Ok(unsafe { h() });

    x
}

pub fn f3c() -> Result<i32, i32> {
    let x = Ok(
        // SAFETY: OK.
        #[allow(clippy::unnecessary_cast)]
        unsafe { h() }
    );

    x
}
@ojeda ojeda changed the title undocumented_unsafe_blocks false positives undocumented_unsafe_blocks false positives around attributes Jul 30, 2024
@ojeda
Copy link
Contributor Author

ojeda commented Aug 4, 2024

Not sure if I can do this, but:

@rustbot label +C-bug +I-false-negative

@rustbot 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
@ojeda
Copy link
Contributor Author

ojeda commented 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 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
Projects
None yet
Development

No branches or pull requests

2 participants