Wrong warning message when using `?` on a expression of type `Result<Infallible, Infallible>` on the 1.92.0-beta.1

[TethysSvensson]

I tried this code:

use std::convert::Infallible;

pub struct Error;

impl From<Infallible> for Error {
    fn from(value: Infallible) -> Self {
        match value {}
    }
}

pub fn bad() -> Result<Infallible, Error> {
    let x: Result<Infallible, Infallible> = Ok(Err(Error)?);
    Ok(x?)
}

In rust 1.92.0-beta.1 that will result in this warning:

warning: unused variable: `val`
  --> src/lib.rs:13:8
   |
13 |     Ok(x?)
   |        ^^ help: if this is intentional, prefix it with an underscore: `_val`
   |
   = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default

warning: `bad` (lib) generated 1 warning (run `cargo fix --lib -p bad` to apply 1 suggestion)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.05s

Notice that the warning refers to a variable val which does not exist in the code.

If I try to run the suggested command, then I get a warning: failed to automatically apply fixes suggested by rustc to crate bad.

This example is a minimized version of actual code generated by the planus code generator. We encountered it because our CI is set up to automatically run on the beta branch.

The original code had a function returning Result<EmptyEnum, ReasonableError> (which would obviously always return an error).

This function was used in an expression similar to this: get_field()?.try_into()?, where the TryInto was actually an identity conversion from EmptyEnum to EmptyEnum using the catch-all impl. This means that the final question mark ran on an expression of type Result<EmptyEnum, Infallible>.

I expected to see this happen: A reasonable warning

Instead, this happened: An unintelligible warning, which causes cargo fix to fail.

rustc --version --verbose:

rustc 1.92.0-beta.1 (3b4dd9bf1 2025-10-28)
binary: rustc
commit-hash: 3b4dd9bf1410f8da6329baa36ce5e37673cbbd1f
commit-date: 2025-10-28
host: x86_64-unknown-linux-gnu
release: 1.92.0-beta.1
LLVM version: 21.1.3

[TethysSvensson]

According to cargo-bisect-rustc the change in behavior was introduced in #142390, which also makes sense to me given the title of the PR

[apiraino]

bisection points to the same root cause of so #148418 probably they're related