diverging function with wrapped diverging tail expression regression

[Dushistov]

Such code:

#[allow(dead_code)]
fn _assert_pointers_are_64bits() -> ! {
    unsafe {
        ::std::mem::transmute::<*const f64, [u8; 8]>(panic!())
    }
}

fn main() {
}

compiled just fine with stable(1.11.0 (9b21dcd 2016-08-15)),
but failed with beta(rustc 1.12.0-beta.1 (822166b 2016-08-16)) and
nightly(rustc 1.13.0-nightly (499484f 2016-08-18)) with such error:

error[E0308]: mismatched types
 --> bug.rs:4:9
  |
4 |         ::std::mem::transmute::<*const f64, [u8; 8]>(panic!())
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected !, found array of 8 elements
  |
  = note: expected type `!`
  = note:    found type `[u8; 8]`

error: aborting due to previous error

[Aatch]

I assume this is related to the recent changes to how we treat !.

/cc @rust-lang/compiler

[eddyb]

@canndrew Did you remove some sort of codepath that assumed a call with diverging arguments is also diverging?

[arielb1]

Nothing to do with transmute:

fn _assert_pointers_are_64bits() -> ! {
    [panic!()]
}

fn main() {}

Stable has something that marks unreachable pointers as type variables.

[arielb1]

Ah well. The issue here is that now, because ! is a type, typeck checks that the final expression of a diverging function has type ! (which it doesn't).

The older check was liveness's more general check that diverging functions don't return (see e.g. #31617), which observes that panic!() never returns.

As a fix, we can pass NoExpectation when the return type is ! - https://github.com/rust-lang/rust/blob/stable/src/librustc_typeck/check/mod.rs#L683.

[arielb1]

Note that adding a semicolon to the expression also makes things compile on all versions (as it goes straight to the liveness check at https://github.com/rust-lang/rust/blob/4901896/src/librustc/middle/liveness.rs#L1503), even if the function returns something other than !:

fn _assert_pointers_are_64bits() -> String {
    [panic!()];
}

Maybe we should just let this one slip?

[eddyb]

Using NoExpectation seems like the direct fix, yes.

[durka]

Talked to @eddyb on IRC, I will try to fix this (he told me exactly what to write so hopefully it will be straightforward :D).