Provide a way to run a test that needs an external dependency

[RalfJung]

It would be pretty neat if we had a way to have ./miri run work on tests that need external dependencies -- right now, these are a bit annoying to debug (and for tests that call into libc, this is a regression compared to the state before we added support for test dependencies). This should probably be a separate ./miri run-dep or so, and as much as possible it should share the test-dependencies infrastructure with ui_test/compiletest.

[RalfJung]

I just ran into this yesterday, where I wanted to just run some files as a quick test, and the libc dependency became a problem. So it'd be great to have some sort of solution here.

[oli-obk]

I'd prefer to run this via ./miri test, what is missing from ./miri test tests/pass-dep/some_test.rs for this to be useful for you?

[RalfJung]

This should work for files outside of the test folder. It should also not compare the output to any stderr/stdout files, nor write any stderr/stdout files itself. It should ignore magic test comments. It should just run the file and not have any expectations about the exit code.

Using ./miri test kind of works but it is a crude work-around -- there's a lot of junk in the output, one has to put the file into a particular folder, one cannot overwrite the magic comments.

[RalfJung]

This would also have been really useful to debug rust-lang/futures-rs#2669.

Judging from oli-obk/ui_test#11 being closed, looks like this "just" needs some wiring up in Miri?

[oli-obk]

Ah yes, I forgot about this one after implementing the ui_test side of things

[oli-obk]

I won't get to this this year and January will most likely be spent catching up on other things. Will pick it up again after that.

[RalfJung]

This works great, thanks!

However printing the entire invocation makes this very verbose and makes it easy to miss the actual program output. Maybe this should be hidden, at least by default?

[oli-obk]

We can just stop emitting that. I thought it may be practical if something goes wrong but I don't see a good way to hide it conditionally. We could make it a flag before the file name I guess?

[RalfJung]

If something goes wrong I'd probably rather debug ./miri run and cargo miri run than the complicated dep setup.

So yeah for now I'd vote for not emitting that.