Skip to content

clippy::redundant_closure: false positive when function returns ! but closure doesn't #8416

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

Closed
Allen-Webb opened this issue Feb 11, 2022 · 3 comments · Fixed by #8431
Closed
Assignees
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

@Allen-Webb
Copy link

Allen-Webb commented Feb 11, 2022

Summary

For tests I have a mock for std::process::exit() that needs to return, so when std::process::exit() is passed in as the callback I wrap it in a closure to change the return type from ! to ().

Lint Name

clippy::redundant_closure

Reproducer

I tried this code:

fn do_thing_with_exit<F: FnMut(i32)>(mut exit_provider: F) {
    //Do thing
    exit_provider(0);
}

fn main() {
    // Example test code:
    let mut ret_code = -1i32;
    do_thing_with_exit(|v| { ret_code = v; });
    assert_eq!(ret_code, 0);

    // Example non-test code:
    do_thing_with_exit(|v| std::process::exit(v));
}

I saw this happen:

warning: redundant closure
  [--> src/main.rs:13:24
](https://play.rust-lang.org/#)   |
13 |     do_thing_with_exit(|v| std::process::exit(v));
   |                        ^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace the closure with the function itself: `std::process::exit`
   |
   = note: `#[warn(clippy::redundant_closure)]` on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_closure

I applied the suggestion:

fn do_thing_with_exit<F: FnMut(i32)>(mut exit_provider: F) {
    //Do thing
    exit_provider(0);
}

fn main() {
    // Example test code:
    let mut ret_code = -1i32;
    do_thing_with_exit(|v| { ret_code = v; });
    assert_eq!(ret_code, 0);

    // Example non-test code:
    do_thing_with_exit(std::process::exit);
}

This fails to compile with the error:

error[[E0271]](https://doc.rust-lang.org/stable/error-index.html#E0271): type mismatch resolving `<fn(i32) -> ! {exit} as FnOnce<(i32,)>>::Output == ()`
  [--> src/main.rs:13:5
](https://play.rust-lang.org/#)   |
13 |     do_thing_with_exit(std::process::exit);
   |     ^^^^^^^^^^^^^^^^^^ expected `()`, found `!`
   |
   = note: expected unit type `()`
                   found type `!`
note: required by a bound in `do_thing_with_exit`
  [--> src/main.rs:1:26
](https://play.rust-lang.org/#)   |
1  | fn do_thing_with_exit<F: FnMut(i32)>(mut exit_provider: F) {
   |                          ^^^^^^^^^^ required by this bound in `do_thing_with_exit`

For more information about this error, try `rustc --explain E0271`.

Version

I used 1.58.1 stable from play.rust-lang.org.

The clippy version is 0.1.60 (2022-02-10 e646f3d)

Additional Labels

No response

@Allen-Webb Allen-Webb added C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have labels Feb 11, 2022
@dswij
Copy link
Member

dswij commented Feb 14, 2022

@rustbot claim

@giraffate
Copy link
Contributor

It seems to be a duplicate of #7812.

@BartMassey
Copy link

Also appears to be a duplicate of #8091. The reproducer there is quite elegant:

fn exit() -> ! {
    panic!()
}

fn main() {
    let value = Some(8u8);
    println!("{}", value.unwrap_or_else(|| exit()));
}

This is perhaps a type inference bug in the compiler? A function that doesn't return should theoretically be compatible with any function type with the same argument types…

@bors bors closed this as completed in d5c62fd Apr 27, 2022
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

Successfully merging a pull request may close this issue.

4 participants