Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type inference failure in unreachable code #40073

Closed
dhardy opened this issue Feb 24, 2017 · 4 comments

Comments

Projects
None yet
4 participants
@dhardy
Copy link
Contributor

commented Feb 24, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 24, 2017

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

This comment has been minimized.

Copy link

commented Feb 24, 2017

Note that X::B is an unreachable expression.

@dhardy

This comment has been minimized.

Copy link
Contributor Author

commented Feb 25, 2017

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?

@dhardy dhardy changed the title Type inference failure involving match and templated enum Type inference failure in unreachable code Feb 25, 2017

@TimNN

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.