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

[check_result_unit_err]: Recommended fix not possible in no_std #9767

Open
FawazTirmizi opened this issue Nov 1, 2022 · 0 comments
Open

Comments

@FawazTirmizi
Copy link

Description

This lint currently suggests implementing a custom Error type, as seen in the below example:

Running Clippy on a project with the following lib.rs:

#![no_std]

use core::result::Result;

pub fn ret_err() -> Result<(),()> {
    if true { Ok(()) } else { Err(()) }
}

will yield the following warning:

warning: this returns a `Result<_, ()>`
 --> src/lib.rs:6:1
  |
6 | pub fn ret_err() -> Result<(),()> {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: use a custom `Error` type instead
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#result_unit_err
  = note: `#[warn(clippy::result_unit_err)]` on by default

However, Error is not available in no_std without enabling the error_in_core feature (tracking issue).

As discussed in #9671, this lint should be suggesting returning a non-unit type as the lint checks that Err is a unit, not that it doesn't implement Error. I think the fix here is to just change the lint to first recommend returning a non-unit type, then suggest one that implements Error, mentioning the feature gate if on no_std. I'd be happy to implement this or whatever other solution people would prefer.

Version

rustc 1.66.0-nightly (a6b7274a4 2022-10-10)
binary: rustc
commit-hash: a6b7274a462829f8ef08a1ddcdcec7ac80dbf3e1
commit-date: 2022-10-10
host: x86_64-unknown-linux-gnu
release: 1.66.0-nightly
LLVM version: 15.0.2

Additional Labels

No response

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

No branches or pull requests

1 participant