Automatic sysroot creation

[DJMcNab]

Although we depend on miri from https://github.com/rust-lang/miri directly, we require that the user installs a sysroot manually using cargo miri setup (since that comes from the miri rustup component). This means we are locked to the version of miri which is in https://github.com/rust-lang/rust. However, it would be better if we could instead use the rustc version which https://github.com/rust-lang/miri compiles with. This would allow us to update more frequently.

In particular, if we make changes to miri (such as https://github.com/rust-lang/miri/pull/1736) then we need to wait for the miri update to reach nightly to use those changes.

cc @ralfjung the easiest way for us to make this possible would be for cargo miri [setup] to be callable as a library, although I suppose we could also install cargo miri directly from the repository. That does seem like a worse solution however.

[oli-obk]

we could use something like the ./miri script: https://github.com/rust-lang/miri/blob/master/miri

This should allow us to work completely locally. Maybe we can even the miri script be a wrapper around another script that serves the base functionality that priroda and miri need?

[DJMcNab]

Hmm, we could do something cargo install --git https://github.com/rust-lang/miri -p cargo-miri --target-dir ../target Ideally though we'd be able to ship a single priroda binary, and be able to run it on any rust program, without having to worry about the version of miri the user has installed being incorrect.

It's possible that we'll need some custom setup stuff anyway - I'm not certain what cargo miri setup actually creates, and whether we'd need to create anything custom in that output.

[RalfJung]

I don't understand what this has to do with using miri master vs the miri pinned in the rustc submodule, but if there's a way to make cargo miri a library I'd be open to that.

Although we depend on miri from https://github.com/rust-lang/miri directly, we require that the user installs a sysroot manually using cargo miri setup (since that comes from the miri rustup component).

The two binaries miri and cargo-miri both come from the same repository and are handled the same by rustup. I don't understand why you are saying there is a difference between the two here.

[bjorn3]

Priroda depends on miri the library directly, not miri the executable. It is currently not possible to have executable dependencies.

[oli-obk]

Could we ship the miri library together with the binary so priroda can just use the one from rustup instead of having a git dependency?

[DJMcNab]

That could happen, however the reason I want to depend on main miri is so that we don't have to wait for any updates to miri which we would depend on to reach the submodule update of rust-lang/rust.

[RalfJung]

I see, you are doing

miri = { git = "https://github.com/rust-lang/miri.git", rev = "ea86335318fd06ec964d9a86b187995bda1b6c7d" }

but there is no way to do that for cargo-miri.

From what I know, splitting a crate like cargo-miri into a lib and a bin crate and making the bin crate just a thin wrapper around the lib is pretty straight-forward, so that seems totally acceptable in terms of Miri-side overhead.

[DJMcNab]

Yeah, exactly. I'm sure I'll make the PR after I do #40