rustc 1.92.0-beta3 flags unreachable code where there is none

[maurer]

Code

use std::convert::Infallible;

pub fn foo(f: impl FnOnce () -> Infallible) -> Infallible {
    f()
}

Current output

error[E0601]: `main` function not found in crate `lib`
 --> lib.rs:5:2
  |
5 | }
  |  ^ consider adding a `main` function to `lib.rs`

warning: unreachable expression
 --> lib.rs:5:1
  |
4 |     f()
  |     --- any code following this expression is unreachable
5 | }
  | ^ unreachable expression
  |
note: this expression has type `Infallible`, which is uninhabited
 --> lib.rs:4:5
  |
4 |     f()
  |     ^^^
  = note: `#[warn(unreachable_code)]` (part of `#[warn(unused)]`) on by default

error: aborting due to 1 previous error; 1 warning emitted

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

Desired output

None. Compilation should succeed with no warnings.

Rationale and extra context

The real-world version of this where the lint tripped upon updating the compiler looks like this:

pub fn reset_stack_guards(continuation: impl FnOnce() -> Infallible) -> Infallible {
    sys::android_reset_stack_guards();
    continuation()
}

It is intended that the passed continuation never returns, and no user code exists past it. The fact that it will never return is surfaced to the caller through the type signature.

I understand that there may be MIR which is "unreachable" in this case (the return path), but there is no unreachable user code.

There's currently no way to write the function above without suppressing the modified lint that I can see, because the lint also triggers on

pub fn reset_stack_guards(continuation: impl FnOnce() -> Infallible) -> ! {
    sys::android_reset_stack_guards();
    match continuation() {}
}

If we had never type support, this lint might be reasonable as with #![feature(never_type)] and a signature fn reset_stack_guards(continuation: impl FnOnce() -> !) -> !, the lint does not complain.

Since never types are not stable, this means that a useful, default-enabled lint now reports in non-actionable situations.

Other cases

Rust Version

rustc 1.92.0-beta.3 (f3f12444a 2025-11-09)
binary: rustc
commit-hash: f3f12444a017add0468f683f3a10656d29438a05
commit-date: 2025-11-09
host: x86_64-unknown-linux-gnu
release: 1.92.0-beta.3
LLVM version: 21.1.3

Anything else?

No response

[maurer]

cc @cjgillot

[workingjubilee]

Does this recur on nightly, @maurer?

[workingjubilee]

It does, it seems. It seems unlikely this will be fixed by #149147 so I suppose this is a new case.