Incorrect "match arms have incompatible types" error message

[offlinemark]

I have code that matches on a Result<usize>, with cases for Ok(usize_var) and Err(why). I get a "match arms have incompatible types" error upon compilation which I believe is incorrect.

I'm not incredibly experienced with this, but discussion in irc (https://botbot.me/mozilla/rust/2015-04-06/?msg=35985521&page=37) supports that this may be a bug.

I tried this code (available at http://is.gd/Y00aRi):

fn main() {
    let mut input: String = String::new();
    match std::io::stdin().read_line(&mut input) {
        Ok(bytes_read) => bytes_read,
        Err(why) => panic!("{}", why)
    }
    println!("{}", input);
}

I expected it to compile, however there is a "match arms have incompatible types" error even though I believe the match arms should both be of type usize.

I should note that adding a semicolon after the match causes clean compilation.

[ftxqxd]

(@steveklabnik I don't think the A-diagnostics label is appropriate for this issue. The bug is that this gives an error at all, not that the error message is bad, so perhaps I-wrong would be better?)

[steveklabnik]

I mean, it's a very bad error regardless, but yeah, maybe. I'll add it too.

[offlinemark]

My rustc version, if it helps

$ rustc --verbose --version
rustc 1.0.0-beta (9854143cb 2015-04-02) (built 2015-04-02)
binary: rustc
commit-hash: 9854143cba679834bc4ef932858cd5303f015a0e
commit-date: 2015-04-02
build-date: 2015-04-02
host: x86_64-apple-darwin
release: 1.0.0-beta

[lilyball]

Yielding an error is correct here. The error message is merely misleading.

The core issue here is your first match arm is attempting to evaluate to a usize value, but the entire match statement is not semicolon-terminated. If you replace the panic!() with, say, 42, you get a similar error:

<anon>:3:5: 6:6 error: mismatched types:
 expected `()`,
    found `usize`
(expected (),
    found usize) [E0308]
<anon>:3     match std::io::stdin().read_line(&mut input) {
<anon>:4         Ok(bytes_read) => bytes_read,
<anon>:5         Err(why) => 42
<anon>:6     }

This is also a bit misleading. The error looks like this because the match expression occurs in statement position, so either the match expression needs to resolve to the type () or it needs to be semicolon-terminated. The error here could definitely be better. In your case, the error is about the match arms having different types because Rust apparently decides to unify the panic!() with the expected () return value, instead of with the first match arm's usize value. If it resolved it with the usize then you'd see the error I listed above instead.

[lilyball]

Given that, I'm removing I-wrong.

[ftxqxd]

@kballard Huh, you're right. I always assumed that adding a semicolon to a statement-position match shouldn't ever change anything.

[lilyball]

Funnily enough, just the other day in IRC @bstrie discovered the exact same thing :)

[ghost]

Another interesting test case, by @Binero from #24568, that we should include as part of the fix:

fn main() {
    is_one(1)
}

fn is_one(a: u8) {
    match a {
        1 => true,
        _ => panic!("It's not one!"),
    }
}

<anon>:6:5: 9:6 error: match arms have incompatible types:
 expected `bool`,
    found `()`
(expected bool,
    found ()) [E0308]
<anon>:6     match a {
<anon>:7         1 => true,
<anon>:8         _ => panic!("It's not one!"),
<anon>:9     }
<anon>:8:14: 8:38 note: match arm with an incompatible type
<anon>:8         _ => panic!("It's not one!"),
                      ^~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
playpen: application terminated with error code 101
Program ended.

[rbtcollins]

Just to note, that this is super confusing for new rust developers - I sought help in #rust after beating my head on the wall for a bit :)

[fungos]

Another code that to me looks the same issue or even #35685. But it is a little different so I'm not really sure if should open a new issue:

pub trait Foo {}

struct Bar;
struct Baz;

impl Foo for Bar { }
impl Foo for Baz { }

fn not_all_paths(a: &str) -> u32 {
    match a {
        "baz" => 0,
        _ => 1,
    }; // "not all control paths return a value" due to ;
}

fn right(b: &str) -> Box<Foo> {
    match b {
        "baz" => Box::new(Baz),
        _ => Box::new(Bar),
    }
}

fn wrong(c: &str) -> Box<Foo> {
    match c {
        "baz" => Box::new(Baz),
        _ => Box::new(Bar),
    }; // "match arms have incompatible types" due to ;
}

fn main() {
}

Play here: https://is.gd/GTv1gf
Using: rustc 1.14.0-nightly (7c69b0d 2016-11-01)

[nambrot]

Could someone outline what the recommended approach is for differently typed match arms? What do I do with options where i want to just run a operation in the Some case but ignore in the None case?

[Mark-Simulacrum]

So I think the fix here would involve basically throwing away individual match arms, returning () instead of their type so as to "unify" when the match is in statement position. This seems relatively fine, but cc @rust-lang/lang -- would we need an RFC for this? Is that the correct interpretation of the best option?

[withoutboats]

The current behavior seems preferable to a change to me.

In all of these cases you are doing something quite unidiomatic, and in several the programmer has almost certainly made a mistake and should receive an error. For example:

fn is_one(a: u8) {
    match a {
        1 => true,
        _ => panic!("It's not one!"),
    }
}

It seems clear to me that this function is supposed to return bool; if you change the return type, it will compile.

For the rest of them I see similar errors.

There are diagnostics issues, but I definitely think nothing should change about the semantics.

[nikomatsakis]

I agree with @withoutboats that this is a purely diagnostic issue.

[estebank]

Updated to Jan 2019:

For @withoutboats case, the output is the original error:

error[E0308]: match arms have incompatible types
 --> src/main.rs:6:5
  |
6 | /     match a {
7 | |         1 => true,
8 | |         _ => panic!("It's not one!"),
9 | |     }
  | |_____^ expected bool, found ()
  |
  = note: expected type `bool`
             found type `()`
note: match arm with an incompatible type
 --> src/main.rs:8:14
  |
8 |         _ => panic!("It's not one!"),
  |              ^^^^^^^^^^^^^^^^^^^^^^^
  = note: this error originates in a macro outside of the current crate

But if we "fix" the incompatible arms "problem", we get get a suggestion to change the return type:

error[E0308]: mismatched types
 --> src/main.rs:8:40
  |
5 | fn is_one(a: u8) {
  |                  - help: possibly return type missing here?: `-> bool `
...
8 |         _ => {panic!("It's not one!"); false},
  |                                        ^^^^^ expected (), found bool
  |
  = note: expected type `()`
             found type `bool`

I'm guessing that adding that suggestion to match arms have incompatible types would be worthwhile (maybe with a suggestion to add a semicolon at the end of the match as we do in some cases, but I don't think that's as worthwhile).

---

@fungos's code now produces a code suggestion to remove the incorrect semicolons:

error[E0308]: mismatched types
  --> src/main.rs:9:30
   |
9  | fn not_all_paths(a: &str) -> u32 {
   |    -------------             ^^^ expected u32, found ()
   |    |
   |    this function's body doesn't return
...
13 |     }; // "not all control paths return a value" due to ;
   |      - help: consider removing this semicolon
   |
   = note: expected type `u32`
              found type `()`

error[E0308]: match arms have incompatible types
  --> src/main.rs:24:5
   |
24 | /     match c {
25 | |         "baz" => Box::new(Baz),
26 | |         _ => Box::new(Bar),
   | |              ------------- match arm with an incompatible type
27 | |     }; // "match arms have incompatible types" due to ;
   | |_____^ expected struct `Baz`, found struct `Bar`
   |
   = note: expected type `std::boxed::Box<Baz>`
              found type `std::boxed::Box<Bar>`

error[E0308]: mismatched types
  --> src/main.rs:23:22
   |
23 | fn wrong(c: &str) -> Box<Foo> {
   |    -----             ^^^^^^^^ expected struct `std::boxed::Box`, found ()
   |    |
   |    this function's body doesn't return
...
27 |     }; // "match arms have incompatible types" due to ;
   |      - help: consider removing this semicolon
   |
   = note: expected type `std::boxed::Box<(dyn Foo + 'static)>`
              found type `()`

[estebank]

I believe there's little room for improvement here beyond what has been done so far:

error[E0308]: match arms have incompatible types
 --> src/main.rs:5:21
  |
3 | /     match std::io::stdin().read_line(&mut input) {
4 | |         Ok(bytes_read) => bytes_read,
  | |                           ---------- this is found to be of type `usize`
5 | |         Err(why) => panic!("{}", why)
  | |                     ^^^^^^^^^^^^^^^^^ expected usize, found ()
6 | |     }
  | |_____- `match` arms have incompatible types
  |
  = note: expected type `usize`
             found type `()`
  = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0308]: match arms have incompatible types
 --> src/main.rs:8:14
  |
6 | /     match a {
7 | |         1 => true,
  | |              ---- this is found to be of type `bool`
8 | |         _ => panic!("It's not one!"),
  | |              ^^^^^^^^^^^^^^^^^^^^^^^ expected bool, found ()
9 | |     }
  | |_____- `match` arms have incompatible types
  |
  = note: expected type `bool`
             found type `()`
  = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

[workingjubilee]

Triage report: emits the correct diagnostic for Rust Edition 2021, and thus we could close this, but before we do so, I should note that I added the caveat there quite deliberately as this actually emits the wrong diagnostic still, in a very weird way, on Edition 2015 and Edition 2018:

Compiling playground v0.0.1 (/playground)
error[[E0308]](https://doc.rust-lang.org/stable/error-index.html#E0308): `match` arms have incompatible types
 [--> src/main.rs:5:21
](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018#)  |
3 | /     match std::io::stdin().read_line(&mut input) {
4 | |         Ok(bytes_read) => bytes_read,
  | |                           ---------- this is found to be of type `usize`
5 | |         Err(why) => panic!("{}", why)
  | |                     ^^^^^^^^^^^^^^^^^ expected `usize`, found `()`
6 | |     }
  | |_____- `match` arms have incompatible types
  |
  = note: this error originates in the macro `$crate::panic::panic_2015`
  (in Nightly builds, run with -Z macro-backtrace for more info)

stable/nightly doesn't seem to matter. rustc version is 1.61.0

[estebank]

@workingjubilee, I agree that the ticket should remain open, although with a lower priority :)

Thanks for triaging!

[arkivm]

Sorry for bumping on the existing issue. But the problem I encounter is very relevant to this issue.

The snippet (playground)

fn exit_wrapper() {
    std::process::exit(1)
}

fn main() {
    let mut input: String = String::new();
    match std::io::stdin().read_line(&mut input) {
        Ok(u) => u,
        Err(_e) => exit_wrapper(),
    };
}

errors with

   Compiling playground v0.0.1 (/playground)
error[[E0308]](https://doc.rust-lang.org/nightly/error-index.html#E0308): `match` arms have incompatible types
  --> src/main.rs:9:20
   |
7  | /     match std::io::stdin().read_line(&mut input) {
8  | |         Ok(u) => u,
   | |                  - this is found to be of type `usize`
9  | |         Err(_e) => exit_wrapper(),
   | |                    ^^^^^^^^^^^^^^ expected `usize`, found `()`
10 | |     };
   | |_____- `match` arms have incompatible types

For more information about this error, try `rustc --explain E0308`.
error: could not compile `playground` due to previous error

However, it compiles when I explicitly annotate the exit_wrapper with a return type -> !.
Is it unreasonable to expect the compiler to deduce the type of exit_wrapper function automatically to !?

[workingjubilee]

Is it unreasonable to expect the compiler to deduce the type of exit_wrapper function automatically to !?

Basically: yes. You are asking for the deduction Rust decided to not attempt.

Function signatures are a coercion site and must remain stable despite their interior for various other stability promises to mean much, so the function signature must dominate over whatever the contents are. This is relaxed in very specific cases, but those cases are ones where a type can be inferred along the "exterior" of the function signature, and the "interior" will not have any meaningful effect on the type deduced.

[arkivm]

Thank you @workingjubilee. That clarifies my question. Also, thanks for posting an explanation on the mentioned issue.

[estebank]

Maybe the diagnostic could attempt to perform that analysis on exit_wrapper() to see if it could return ! and suggest that code, and either way we should be pointing at line 1 stating "exit_wrapper returns ()".

[estebank]

current output for the original report:

error[E0308]: mismatched types
 --> src/main.rs:3:5
  |
3 | /     match std::io::stdin().read_line(&mut input) {
4 | |         Ok(bytes_read) => bytes_read,
5 | |         Err(why) => panic!("{}", why)
6 | |     }
  | |     ^- help: consider using a semicolon here
  | |_____|
  |       expected `()`, found `usize`

There has been no movement in trying to probe a called function that returns () to see if it could be ! instead. I'm not sure if we will.

[majaha]

I've made an interesting minimal contrasting pair that showcases this diagnostic issue: Playground

If you build the code:

fn never() -> ! {
    loop {}
}

fn foo(a: bool) {
    match a {
        true => 1,
        false => never(),
    }
}

you get the error

error[E0308]: mismatched types
 --> src/lib.rs:7:17
  |
7 |         true => 1,
  |                 ^ expected `()`, found integer
  |
help: consider using a semicolon here
  |
9 |     };
  |      +
help: try adding a return type
  |
5 | fn foo(a: bool) -> i32 {
  |                 ++++++

which is acceptable, and has useful help: tips that guide you in the right direction. However, if you wrap the never() in a { block }, like so:

fn bar(a: bool) {
    match a {
        true => 1,
        false => {
            never()
        }
    }
}

then you get the error:

error[E0308]: `match` arms have incompatible types
  --> src/lib.rs:16:13
   |
13 | /     match a {
14 | |         true => 1,
   | |                 - this is found to be of type `{integer}`
15 | |         false => {
16 | |             never()
   | |             ^^^^^^^ expected integer, found `()`
17 | |         }
18 | |     }
   | |_____- `match` arms have incompatible types

For more information about this error, try `rustc --explain E0308`.

This error message has several issues.

1. The addition of the brackets has baffled those useful help: tips.
2. It feels like the compiler is lying to you about the type of never(), pointing directly at it and saying it "found ()" despite it having type !. I realise that the compiler must have already coerced the type, but it feels kinda gaslight-y.
3. The compiler claims that the match arms have incompatible types, even though this isn't true. Rather, the compiler is coercing types across the boundary of the match statement before coercing between the different arms of the match statement, as you would intuitively expect would happen first.
4. The line fn bar(a: bool) { doesn't appear anywhere in the error message, despite being the source of the inferred () type, and it's being a candidate for the problem line.