Unable to run individual binaries with cargo-miri when multiple binaries exist

[jacob-hughes]

Consider a cargo project with multiple binaries inside src/bin/:

$ tree src
src
└── bin
    ├── a.rs
    └── b.rs

1 directory, 2 files

Invoking cargo miri run runs each binary through miri, one after the other. I'm not sure whether this is behaviour is intentional, since cargo run would complain about the ambiguity of which target to run.

Unfortunately, however, should a cause miri to error, miri will exit. This means b is never run.

What's more, specifying a single target to run via the --bin argument, causes miri to error:

$ cargo miri run --bin a
error: extra arguments to `rustc` can only be passed to one target, consider filtering
the package by passing, e.g., `--lib` or `--bin NAME` to specify a single target

I'm assuming this is because miri run is really just a wrapper around a custom rustc driver which starts the miri interpreter. If this is true, how can I tell miri to only run a specified binary? And how can I ensure that b runs regardless of the result of a?

Thanks for the help!

Miri Version

$ cargo miri --version           
miri 0.1.0 (75417e5 2020-01-31)  

[RalfJung]

I think this is a duplicate of #739 -- could you check?

Your analysis is correct, the current cargo wrapper is a pretty bad hack. We'd have to re-implement the binary (and test) selection that cargo is doing ourselves, which seems silly, so I was hoping to find some other approach for this -- but it's not been a high priority.

A work-around is to use the miri binary directly, which is the underlying "driver" for cargo miri. It behaves like rustc, except instead of generating code it interprets the program.

Also note #1136, which changes the way we interact with cargo and might or might not make this easier to fix.

[jacob-hughes]

Hi @RalfJung

I think this is a duplicate of #739 -- could you check?

You're right. Sorry I missed this one.

A work-around is to use the miri binary directly, which is the underlying "driver" for cargo miri. It behaves like rustc, except instead of generating code it interprets the program.

I'll give this one a go, thanks. I'll close this as a duplicate.