Spurious verbose_file_reads in one arm of an if/else

Summary

It's simplest to just look at the reproducer. but, in short, verbose_file_reads isn't taking into account that the File::open is outside an if/else block and the File::read_to_string is inside only one of the branches.

Lint Name

verbose_file_reads

Reproducer

I tried this code:

        let mut file = File::open(&inpath)?;
        if inpath.extension() == Some(OsStr::new("gz")) {
            GzDecoder::new(file).read_to_string(&mut raw_str)?;
            inpath.set_extension("");
        } else {
            file.read_to_string(&mut raw_str)?;
        }

I saw this happen:

warning: use of `File::read_to_string`
  --> src/app.rs:86:13
   |
86 |             file.read_to_string(&mut raw_str)?;
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: the lint level is defined here
  --> src/main.rs:10:40
   |
10 | #![warn(clippy::all, clippy::pedantic, clippy::restriction)]
   |                                        ^^^^^^^^^^^^^^^^^^^
   = note: `#[warn(clippy::verbose_file_reads)]` implied by `#[warn(clippy::restriction)]`
   = help: consider using `fs::read_to_string` instead
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#verbose_file_reads

I expected to see this happen:

Nothing. The use of File::read_to_string only occurs in one branch of an if where the other branch is ineligible to use fs::read_to_string.

Version

rustc 1.56.1 (59eed8a2a 2021-11-01)
binary: rustc
commit-hash: 59eed8a2aac0230a8b53e89d4e99d55912ba6b35
commit-date: 2021-11-01
host: x86_64-unknown-linux-gnu
release: 1.56.1
LLVM version: 13.0.0

Additional Labels

No response

Use the reproducer in the issue to confirm the verbose_file_reads warning, then locate that lint's implementation and regression-test coverage. Trace how the lint evaluates the if/else branches and verify that the reported warning disappears when only one branch is eligible for fs::read_to_string.