`unused_io_amount` false positive if the result is matched by `Ok(<literal>)` or `unreachable!()` cases

[oxalica]

Summary

See the reproducer. I believe it's introduced by #12005. cc @partiallytyped

I saw there are two issues:

1. We should consider Ok(<literal>) as used, as the read amount is actually checked.
2. We should consider Ok(_) => unreachable!() as used, as we are explicitly asserting the read must fail for some reason. I'm not quite sure how exactly we should do this. As simply checking if the arm has type ! would instead yield a false-negative for Ok(_) => return.

Lint Name

unused_io_amount

Reproducer

Given this code (playground):

pub fn work(rdr: &mut dyn std::io::Read) {
    match rdr.read(&mut [0]) {
        Ok(0) => println!("EOF"),
        Ok(_) => println!("fully read"),
        Err(_) => println!("fail"),
    }
}

pub fn work2(rdr: &mut dyn std::io::Read) {
    match rdr.read(&mut [0]) {
        Ok(_) => unreachable!(),
        Err(_) => println!("expected"),
    }
}

I saw this happen:

error: read amount is not handled
 --> src/lib.rs:2:11
  |
2 |     match rdr.read(&mut [0]) {
  |           ^^^^^^^^^^^^^^^^^^
  |
  = help: use `Read::read_exact` instead, or handle partial reads
note: the result is consumed here, but the amount of I/O bytes remains unhandled
 --> src/lib.rs:4:9
  |
4 |         Ok(_) => println!("fully read"),
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unused_io_amount
  = note: `#[deny(clippy::unused_io_amount)]` on by default

error: read amount is not handled
  --> src/lib.rs:10:11
   |
10 |     match rdr.read(&mut [0]) {
   |           ^^^^^^^^^^^^^^^^^^
   |
   = help: use `Read::read_exact` instead, or handle partial reads
note: the result is consumed here, but the amount of I/O bytes remains unhandled
  --> src/lib.rs:11:9
   |
11 |         Ok(_) => unreachable!(),
   |         ^^^^^^^^^^^^^^^^^^^^^^^
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unused_io_amount

I expected to see this happen: no errors or warnings emitted.

Version

(Playground) 0.1.77 (2024-01-27 6b4f1c5)

Additional Labels

No response

[PartiallyUntyped]

@blyxyas what do you think?

I am not really sure what the "right" way to handle this is tbh; and I think I just opened a whole new can of worms 🤔.

[FreezyLemon]

Hey, not sure if this is the exact same problem but it seems related. Calling .read and handling the result with the ? operator inside a block expression also triggers a false positive (Playground link):

pub fn work(rdr: &mut dyn std::io::Read) -> std::io::Result<usize> {
    let read = { rdr.read(&mut [0])? };
    Ok(read)
}

This does not happen on stable. Removing the braces will fix it:

pub fn work2(rdr: &mut dyn std::io::Read) -> std::io::Result<usize> {
    let read = rdr.read(&mut [0])?;
    Ok(read)
}

[blyxyas]

what do you think?

The reporter is right, Ok(<literal>) should not lint, that should be easy to implement. I'm not sure how to handle Ok(_) => <panic> thought. False negatives with //TODOs are better than false positives in almost all cases.

I've put this issue in Priority High, we should address it pretty quickly (before it reaches stable)

[PartiallyUntyped]

@blyxyas

Ok, so in case any literal exists on an ok arm we will consider this covered.

What about cases with arm guards?

I am on it, I began fixing this.

[blyxyas]

I'd say that an arm guard would mean that it's covered. Maybe the guard calls a function to do the checking (unnecessarily complex, but it's still handling)