Poor diagnostics on missing semicolon after match statement

[moxian]

I tried this code (playground):

fn stuff() -> i32 {
    match 1i32 {
        2i32 => 3i32,
        _ => panic!("wrong"),
    }
    4i32
}

I expected to see this happen:
A compiler error about missing ; between } and 4i32

Instead, this happened:

error[E0308]: `match` arms have incompatible types
 --> src/lib.rs:4:14
  |
2 | /     match 1i32 {
3 | |         2i32 => 3i32,
  | |                 ---- this is found to be of type `i32`
4 | |         _ => panic!("wrong"),
  | |              ^^^^^^^^^^^^^^^ expected `i32`, found `()`
5 | |     }
  | |_____- `match` arms have incompatible types
  |
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

This is very confusing, because I "know" that panic!() return type is ! which is coercible to anything else (or whatever is the technical explanation for "we can really ignore the return type of panic!"), so it should not ever be present in error messages about mistyping stuff.

Meta

rustc --version --verbose:

rustc 1.44.0-beta.3 (0f0d70055 2020-05-11)
binary: rustc
commit-hash: 0f0d70055530bdbf3f0acb7b8ad25aa4a6ad8ea9
commit-date: 2020-05-11
host: x86_64-pc-windows-msvc
release: 1.44.0-beta.3
LLVM version: 9.0

This issue is also present in 1.34.2 (from a year ago), and in two-week-old nightly (rustc 1.45.0-nightly (99cb9cc 2020-05-11))

p.s.: When deminimizing the issue, i realized that it's even more confusing when match is the last statement in a for loop (as it was in my real code), i.e.:

fn stuff2(){
    for _ in 0..5{
        match 1i32 {
            2i32 => 3i32,
            _ => panic!("wrong"),
        }
    }
}

gives the same error message about incompatible match arms.

[estebank]

The panic!s ! coerces to () because the whole match needs to evaluate as a statement, not an expression because its return value is ignored. Adding a trailing ; "fixes" the code.

[compiler-errors]

@estebank: As far as I can tell, #106601 didn't fix this issue (you didn't add a test for it either), and the two UI tests that the PR did touch, the suggestion didn't do anything useful -- it only fires when one of the arms is actually evaluated to be type (), rather than being constrained to () due to (lack of) semicolon.

[compiler-errors]

Actually, we do suggest using a semicolon, but not via #106601. I'm just gonna revert that, and add this as a test.