Type inference failure in unreachable code

[dhardy]

The following code works on stable 1.15.1 but not on current nightly compilers (Play editor):

enum X<T> {
    A(T), B
}

fn f(x: u32) -> X<()> {
    match x {
       _ => return X::A(()),
    }
    X::B
}

fn main() {
    f(0);
}

I encountered this using Result but realised a templated enum is sufficient. I can't replicate when replacing the match with an if.

[dhardy]

Maybe I should paste the error message too:

rustc 1.17.0-nightly (0f34b532a 2017-02-21)
error[E0282]: type annotations needed
 --> <anon>:9:5
  |
9 |     X::B
  |     ^^^^ cannot infer type for `T`

error: aborting due to previous error

[leonardo-m]

Note that X::B is an unreachable expression.

[dhardy]

That observation may be the key to it, thanks. I hadn't realised my match expression never returned.

In this case the error makes perfect sense (since X::B is never associated with the return type), but the error is misleading. Why even try to type-check unreachable code?

Simpler version: play

Thinking about it some more, I realise there's a reason unreachable code is usually reported as a warning and not an error (outside the Java world!): because a smarter compiler could make previously "valid" code no longer compile. So that leaves three approaches:

1. Report warnings before errors in certain cases
2. Just revert this change to the compiler and associate the return value (X::B here) with the function's return type even though this value can never actually be returned
3. Or don't type check or compile unreachable code.

Going back to my original use-case, I later added other arms to that match block which didn't all return, and did use the code below it (crazy as it sounds, I was trying to diagnose this error while doing a rebase). In this case, approach (1) would have helped me solve the problem sooner, but meant I'd have had to change the code again later. Approach (3) may have been okay or may have let me commit erroneous code initially, and only report issues when adding other match arms later. So (2) may be the best option?

[TimNN]

Duplicate of #39984; as mentioned there likely caused by #39485 and potentially expected breakage?