The compilation error prompt points to the wrong location

[fawdlstty]

I tried this code:

fn main() {
    let oa = Some(1);
    let oa2 = Some(1);
    let v = if let Some(a) = oa {
        Some(&a)
    } else if let Some(a) = oa2 {
        &Some(a)
    } else {
        None
    };
    println!("{v:?}");
}

I expected to see this happen:

&Some(a)
^^^^^^^^ expected `Option<&{integer}>`, found `&Option<{integer}>`

Instead, this happened:

None
^^^^ expected `&Option<{integer}>`, found `Option<_>`

Meta

rustc --version --verbose:

rustc 1.91.0-nightly (a1208bf76 2025-09-03)
binary: rustc
commit-hash: a1208bf765ba783ee4ebdc4c29ab0a0c215806ef
commit-date: 2025-09-03
host: x86_64-unknown-linux-gnu
release: 1.91.0-nightly
LLVM version: 21.1.0

Backtrace

$> RUST_BACKTRACE=1 cargo build
   Compiling test_proj v0.1.0 (/home/fawdlstty/workspace/test_proj)
error[E0308]: `if` and `else` have incompatible types
  --> src/main.rs:9:9
   |
 6 |       } else if let Some(a) = oa2 {
   |  ____________-
 7 | |         &Some(a)
   | |         -------- expected because of this
 8 | |     } else {
 9 | |         None
   | |         ^^^^ expected `&Option<{integer}>`, found `Option<_>`
10 | |     };
   | |_____- `if` and `else` have incompatible types
   |
   = note: expected reference `&Option<{integer}>`
                   found enum `Option<_>`
help: consider using `Option::expect` to unwrap the `Option<_>` value, panicking if the value is an `Option::None`
   |
10 |     }.expect("REASON");
   |      +++++++++++++++++

For more information about this error, try `rustc --explain E0308`.
error: could not compile `test_proj` (bin "test_proj") due to 1 previous error
$>

[Teapot4195]

The issue here appears to be that the rust compiler type checks the if else chain backwards. e.g.:

let v = if foo {
    [this type is checked against the else branch, to do so the else branch's type is checked]
} else [to get this type, the if branch is checked] if bar {
    [this type is checked against the else branch below]
} else {
    ...
}

It boils down to a recursive call chain, it checks the expression in the if statement and then the else statement, the else branch then calls the checker for the if statement (recursive). It is indeed a little bit unintuitive that the chain is checked backwards, perhaps this should be refactored to check it forwards?

[sgasho]

@rustbot claim

[sgasho]

perhaps this should be refactored to check it forwards?

I encountered an issue while working on this problem using this approach.

I created a thread on Zulip.

https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Struggling.20to.20fix.20issue.20.23146190.20check_expr_if/with/540960074