Unreachable code errors after the never type got stabilized

[ilovepi]

I tried this code:

// RUN: rustc %s --crate-type=lib
// Version rustc 1.100.0-nightly (6510953ce 2026-08-26)

#![deny(unreachable_code)]
use std::convert::Infallible;

pub fn repro_unreachable_expression(res: Result<u32, Infallible>) -> u32 {
    match res {
        Ok(v) => v,
        Err(x) => {
            let x: Infallible = x;
            match x {}
        }
    }
}

pub fn repro_unreachable_call(res: Result<(), Infallible>) -> Result<(), String> {
    res.map_err(|e| e.to_string())
}

I expected to see this happen: No errors or diagnostics.

Instead, this happened: An error diagnostic.

prebuilt/third_party/rust/linux-x64/bin/rustc repro_inlined.rs --crate-type=lib
error: unreachable expression
  --> repro_inlined.rs:12:13
   |
11 |             let x: Infallible = x;
   |                                 - any code following this expression is unreachable
12 |             match x {}
   |             ^^^^^^^^^^ unreachable expression
   |
note: the lint level is defined here
  --> repro_inlined.rs:4:9
   |
 4 | #![deny(unreachable_code)]
   |         ^^^^^^^^^^^^^^^^

error: unreachable call
  --> repro_inlined.rs:18:23
   |
18 |     res.map_err(|e| e.to_string())
   |                     - ^^^^^^^^^ unreachable call
   |                     |
   |                     any code following this expression is unreachable

error: aborting due to 2 previous errors

Meta

rustc --version --verbose:

rustc 1.100.0-nightly (6510953ce 2026-08-26)
binary: rustc
commit-hash: 6510953ce01859dc271e3285cf539e03d0d781e7
commit-date: 2026-08-26
host: x86_64-unknown-linux-gnu
release: 1.100.0-nightly
LLVM version: 24.0.0

We hit this when qualifying a new Toochain for Fuchsia. From what I can tell, this seems like a regression after #155499 landed. There are probably some changes we can make in Fuchsia's Rust code to avoid breaking the build, but I thought its surprising enough to bear reporting, as this wasn't an obvious thing to happen as fallout from that PR. Admittedly, I'm not the sagest of Rust developers, so perhaps it should have been.

In any case, I wanted to raise this and figure out if the maintainers agree this is a regression, and if so how to proceed. If this the diagnostic is the intended behavior, it likely warrants more documentation and maybe a more detailed example in the release notes (or wherever is appropriate), as I think this will break many users.

[asquared31415]

The expressions x and e now have type ! which means that reachability analysis can now see that following expressions cannot be reached. I believe this is an expected (and even desired) change because of Infallible=!. The tracking issue for this change is #155924. Crater runs from various never type change tests did turn up a few deny(unreachable_code) errors (the most I see among the crater runs that I checked is 4 unique crates), so this is at the very least not completely unknown.

Additionally, changes to lints (especially when they become more correct) are not generally considered breaking, unless there's a particularly good reason.

[asquared31415]

@rustbot label -needs-triage +T-libs +A-lints +F-never_type +L-unreachable_code

[WaffleLapkin]

As @asquared31415 pointed out, this is expected behavior. Since #155499 made Infallible a type alias to !, the unreachable code lint detects more code that is unreachable (it checks for ! specifically).

In these examples you can fix the problem by omitting unnecessary branches or using the never-to-any coercion directly (play):

#![deny(unreachable_code)]
use std::convert::Infallible;

pub fn repro_unreachable_expression(res: Result<u32, Infallible>) -> u32 {
    match res {
        Ok(v) => v,
-        Err(x) => {
-            let x: Infallible = x;
-            match x {}
-        }
    }
}

pub fn repro_unreachable_call(res: Result<(), Infallible>) -> Result<(), String> {
-    res.map_err(|e| e.to_string())
+    res.map_err(|e| e)
}