Unreachable code is not borrow-checked

[SNCPlay42]

I tried this code:

fn main() {
    let a = 1;
    
    loop {}
        
    let z = &a;
    let x = &mut a;
    let y = &mut a;
    
    *x = 2;
    *y = 3;
    
    println!("{}", *z);
}

I expected this to fail to compile, since I create one immutable and two mutable borrows of an immutable variable that all have to be alive at once.

It's not unsound to accept this, since none of it is even codegened, but unreachable code is otherwise held to the same standards as reachable code (must type-check, etc.).

Instead, this code is accepted with only warnings:

warning: unreachable statement
 --> src/lib.rs:6:5
  |
4 |     loop {}
  |     ------- any code following this expression is unreachable
5 |         
6 |     let z = &a;
  |     ^^^^^^^^^^^ unreachable statement
  |
  = note: `#[warn(unreachable_code)]` on by default

warning: unused variable: `a`
 --> src/lib.rs:2:9
  |
2 |     let a = 1;
  |         ^ help: if this is intentional, prefix it with an underscore: `_a`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: `playground` (lib) generated 2 warnings

On Rust 1.35 and before, this code was rejected in the 2015 edition (which used the old lexical borrowck).

@rustbot label regression-from-stable-to-stable

[camelid]

I'm not sure if this is really a regression since I'm pretty sure it's expected behavior. Borrow-checking is now a flow-based analysis, so unreachable code can't be borrow-checked I think.

You can also use uninitialized variables in unreachable code, since initialization-checking is also a flow-based analysis (playground):

pub fn foo() -> i32 {
    loop {}

    let x;
    x
}

cc #79735, a similar issue but about the unsafety-checker

[SNCPlay42]

You can also use uninitialized variables in unreachable code, since initialization-checking is also a flow-based analysis

Is this closely related to the borrowck code? I notice that whether this is accepted also depends on whether the edition+rustc version uses NLL borrowck or not.

[inquisitivecrystal]

I think this is expected behavior, per nikomatsakis. I'm sorry I don't have a more canonical source. It does seem to be implied by the NLL RFC, but that requires a fair bit of reading between the lines.

[SNCPlay42]

Hmm. Actually, in terms of initialization-checking the code in my original post, I notice that it is either

1. invalid since there is no control flow path from where a is initialized to where the borrows use it, or
2. valid since those borrows that use a are never reached

And 2 does seem like the less surprising option.

[apiraino]

Adding T-lang nomination to get this issue in their agenda.

Removing prioritization and regression labels as per WG-prioritization discussion on Zulip

@rustbot label -I-prioritize +I-lang-nominated -regression-from-stable-to-stable