Stream: t-compiler/const-eval

Topic: using miri without cargo

Jake Hughes (Feb 11 2020 at 19:40, on Zulip):

Hi, I have a project where I use my own test suite harness (think compile-test but less clever). I'd like to run these tests under miri but from what I can see, cargo-miri assumes that binaries are known by cargo (either via [[bin]] in Cargo.toml or by existing in src/bin/. Instead, we just have a large dir of independent source files, a bit like the test/ dir in rustc. Is it possible to setup and compile things for miri using rustc so that my own test harness (and not cargo-miri) can compile each target independently and dispatch it to cargo-miri run? Thanks!

bjorn3 (Feb 11 2020 at 21:42, on Zulip):

You can use the miri binary instead. I believe it is a drop in replacement for the rustc binary.

Jake Hughes (Feb 12 2020 at 20:44, on Zulip):

Thanks Bjorn! :thumbs_up:

RalfJ (Feb 13 2020 at 09:00, on Zulip):

indeed. :) using this "driver" directly is not very well documented and the flags are less stable, but it should work. if you have any questions, feel free to ask here or open an issue.

Jake Hughes (Feb 13 2020 at 17:27, on Zulip):

Thanks @RalfJ, I'm having a little difficulty using the driver because the file I want to test depends on a crate. Is there a way to use cargo miri to build the crate with the relevant miri flags, and then divert to the driver to actually run the file? Maybe even I could use cargo rustc with the same toolchain as the driver and pass in the relevant flags as arguments?

RalfJ (Feb 13 2020 at 21:24, on Zulip):

@Jake Hughes

Is there a way to use cargo miri to build the crate with the relevant miri flags, and then divert to the driver to actually run the file?

well that's exactly what cargo miri does...^^

RalfJ (Feb 13 2020 at 21:24, on Zulip):

you could do cargo miri -vv to make it show you all the flags for calling the driver the right way

RalfJ (Feb 13 2020 at 21:27, on Zulip):

it'll show something like

     Running `/home/r/.cargo/bin/cargo-miri rustc --crate-name cargo_miri_test --edition=2018 src/ --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C debuginfo=2 cargo-miri-marker-begin cargo-miri-marker-end -C metadata=2eab38112672c0a9 -C extra-filename=-2eab38112672c0a9 --out-dir /home/r/src/rust/miri/test-cargo-miri/target/debug/deps -C incremental=/home/r/src/rust/miri/test-cargo-miri/target/debug/incremental -L dependency=/home/r/src/rust/miri/test-cargo-miri/target/debug/deps --extern byteorder=/home/r/src/rust/miri/test-cargo-miri/target/debug/deps/libbyteorder-6f03af6f96c10631.rlib`
Jake Hughes (Feb 13 2020 at 23:13, on Zulip):

@RalfJ Ah I understand. Unfortunately I have quite a lot of crates that would need manually compiling with the driver this way that it's not really feasible. Is there a flag I can pass to cargo-miri that would let me build the artefacts for miri but not run them? That way I could just pre-build them and link them all on the command line at once with the driver.

RalfJ (Feb 14 2020 at 08:05, on Zulip):

Hm, no... probably the best you can do is add a hack here to just skip the binary you do not want to run

RalfJ (Feb 14 2020 at 08:06, on Zulip):

also there's no "linking" so I dont entirely follow your question

RalfJ (Feb 14 2020 at 08:07, on Zulip):

I also finally figured out the debug flag I actually wanted to recommend: cargo miri run -- -v

RalfJ (Feb 14 2020 at 08:07, on Zulip):

the number of dependencies doesnt matter, this will just build all of them and then run the first binary (and fail, you said), but it'll print the invocation so you can make it run the 2nd binary instead

Jake Hughes (Feb 14 2020 at 19:35, on Zulip):

@RalfJ The penny has dropped -- I see what you mean now. Thanks for the help!

Last update: Feb 25 2020 at 03:40UTC