ICE: unsupported cast [MIR]

[MagaTailor]

Compiling the hpack v0.2.0 crate withrustc 1.10.0-dev (8b1dcf40f 2016-04-29) on ARM Linux:

error: internal compiler error: src/librustc_trans/mir/rvalue.rs:347: unsupported cast: fn(&(&[u8], &[u8])) -> (&[u8], &[u8]) to fn(&'static (&'static [u8], &'static [u8])) -> (&'static [u8], &'static [u8])

or curl:

error: internal compiler error: src/librustc_trans/mir/rvalue.rs:347: unsupported cast: extern "C" fn(*mut u8, usize, usize, *mut http::body::Body<'_>) -> usize to extern "C" fn(*mut u8, usize, usize, *mut http::body::Body<'static>) -> usize

This was my first contact with mir and it wasn't peaceful :) Maybe I should have tried a Hello Mir, erm World instead...

[MagaTailor]

More ICEy stuff:

error: internal compiler error: src/librustc_trans/common.rs:1102: Encountered error `Unimplemented` selecting `Binder(<util::network::host::Host<service::SyncMessage> as util::IoHandler<util::NetworkIoMessage<Message>>>)` during trans

coming from parity/ethcore crate.

[Aatch]

Minimal reproduction:

pub struct Foo<'a> {
    x: fn(&'a i32)
}

pub fn foo<'a>() -> Foo<'a> {
    Foo {
        x: the_fun as fn(&'a i32)
    }
}

fn the_fun<'a>(_: &'a i32) { }

It's the the_fun as fn(&'a i32) that is the problem. What happens is that we first reify the_fun to a function pointer, then try to cast the function pointer itself. It seems that we don't expect an FnPtr -> FnPtr cast in the MIR.

I'm pretty sure that f as fnty is only valid when it's a no-op, so we can probably just handle it MIR translation. @eddyb that seem correct?

[eddyb]

@Aatch I added some code to not build noop casts, the lifetimes may be different here though?

[Aatch]

@eddyb possibly, doing let f: fn(&'a i32) = the_fun; first and using f in the cast works, so I'd say that lifetimes are the most likely source of difference between the two types in the cast. Do we have a lifetime-ignoring comparison we could use in this case?

[eddyb]

@Aatch Problem is, you can't ignore lifetimes, what if this is a *const Foo<'a> to *const Foo<'b> cast?
There might be another way to tell that a cast only triggered a coercion, at the HAIR level.
I'm not aware of casts that have both a coercion and also do something extra.
EDIT: Well, actually, the good old main as u8 is a reification coercion + ptr-to-int cast.

[Aatch]

@petevine do you mind giving a backtrace for that second error and opening a new issue for it (since it's unrelated to the two in the main post).

If you could reduce it to a smaller reproduction, that would be even better.

[MagaTailor]

There were no backtraces, unfortunately.

Let's clarify one thing though - is turning -Z orbit off for a single crate and then resuming the mir'ed build, ok? That's how I arrived at the latter issue. (edit: wasn't the problem)

[Aatch]

This was my first contact with mir and it wasn't peaceful :) Maybe I should have tried a Hello Mir, erm World instead...

Actually MIR compilation has been bootstrappable for the compiler for a while now, so trying to use it for more complex codebases is really valuable, since it finds bugs like this.

[eddyb]

@petevine The compiler doesn't generate a backtrace even if you set RUST_BACKTRACE=1?

[MagaTailor]

That was the case indeed. (both ended in a segfault)

-original message-
Subject: Re: [rust-lang/rust] ICE: unsupported cast MIR
From: Eduard-Mihai Burtescu [email protected]
Date: 01.05.2016 12:22

@petevine The compiler doesn't generate a backtrace even if you set RUST_BACKTRACE=1?

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#33295 (comment)

[MagaTailor]

@Aatch
Yeah, that's why I tried it - that whole sentence was a big pun on the word mir. (meaning both peace and world)