Strange error message when passing ill-typed code to Miri

[RalfJung]

This example shows the following error when hitting "Run":

   Compiling playground v0.0.1 (/playground)
error[E0425]: cannot find function `Droppable` in this scope
 --> src/main.rs:2:17
  |
2 |     let mut x = Droppable(0);
  |                 ^^^^^^^^^ not found in this scope

error[E0425]: cannot find function `Droppable` in this scope
 --> src/main.rs:5:19
  |
5 |     unsafe { *p = Droppable(1); } // prints "dropping 0"
  |                   ^^^^^^^^^ not found in this scope

error: aborting due to 2 previous errors

But when I send it to Miri, I get

error[E0460]: found possibly newer version of crate `core` which `unicode_width` depends on
  |
  = note: perhaps that crate needs to be recompiled?
  = note: the following crate versions were found:
          crate `core`: /root/.cache/miri/HOST/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-00869b21179267d6.rlib
          crate `unicode_width`: /playground/target/debug/deps/libunicode_width-f959371afbea1e81.rlib

error: aborting due to previous error

[shepmaster]

found possibly newer version of crate

This is for any usage of Miri on the playground which includes a crate:

fn main() {
    memchr::memchr(0, &[]);
}

This has been present since Miri was introduced on the playground, AFAIR; TBH I assumed that Miri didn't handle crates yet.

[shepmaster]

I wonder if this shares commonalities with rust-lang/rust#57854, which is a similar "why is an external crate coming into play anyway".

[RalfJung]

But my example doesn't use a crate, does it?

Miri works fine with crates locally.

[RalfJung]

How do these other crates get built? Maybe the issue is that they don't get built against Miri's sysroot.

[shepmaster]

But my example doesn't use a crate, does it?

Right, and neither does the linked issue. Both just have the crates "hanging around".

[shepmaster]

How do these other crates get built?

Miri starts from the existing nightly container.

The base compiler containers just run cargo build

Maybe the issue is that they don't get built against Miri's sysroot.

Very likely. Does this mean that the Miri container needs to rebuild all the crates? Clippy already does this, so it might be time to reorganize the build process.

[RalfJung]

Does this mean that the Miri container needs to rebuild all the crates?

Yes. They have to be built against the sysroot in ~/.cache/miri/HOST.

[shepmaster]

They have to be built against the sysroot in ~/.cache/miri/HOST.

What's the invocation for that? You're more familiar with our build process w.r.t. Miri.

[RalfJung]

You have a Cargo.toml will all the deps, right? Doing cargo clean && cargo miri run in that project dir should be sufficient.

[shepmaster]

cargo clean

Is this required? Docker has additive filesystems, deleting stuff from a previous layer doesn't save any space.

cargo miri run

Presumably with at least a fn main() {}? There is no main.rs or lib.rs inside the container.

[RalfJung]

Without the clean I am worried it will just not do anything as the previously compiled libs are still around.

Yes, having an empty main makes sense (or the command will likely fail -- it did all its work by then, but still, that'd be ugly).

[shepmaster]

Implicitly fixed by #460 ?

[RalfJung]

Indeed, thanks :)