Diagnostics about building a sysroot should include where that sysroot is.

[pnkfelix]

Miri emits some helpful messages when it is doing the somewhat long running operation of preparing the initial sysroot.

But, when it does this in response to cargo miri run, it does not tell the user where that sysroot is located; it just says:

Preparing a sysroot for Miri (target: x86_64-unknown-linux-gnu)... done

When you run cargo miri setup, things are a little better, in that it will emit a note at the end saying where the sysroot was:

Preparing a sysroot for Miri (target: x86_64-unknown-linux-gnu)... done
[... gobs of output ...]
    Finished release [optimized] target(s) in 20.45s
A sysroot for Miri is now available in `/home/pnkfelix/.cache/miri`.

But if someone Ctrl-C's the above, or if it hits an error without finishing successfully, then the user will again not know where the sysroot is that Miri prepared is located.

---

I think the fix here should probably be simple, e.g. in those initial diagnostics that say "Preparing a sysroot for Miri (target: x86_64-unknown-linux-gnu)... ", they could be elaborated to now say: "Preparing a sysroot for Miri (target: x86_64-unknown-linux-gnu, destination: /path/to/sysroot)..."

[RalfJung]

This was deliberate, since I didn't want to spam the user's terminal with a long and ugly path on each and every cargo miri run. Presumably, for that command the user does not care much about the sysroot, they want to just run their code. On the other hand, cargo miri setup is explicitly asking about the sysroot so we are more verbose.

Why do you want to see that path?

[RalfJung]

But if someone Ctrl-C's the above, or if it hits an error without finishing successfully,

It there's an error we print:

failed to build sysroot; run cargo miri setup to see the error details

The goal of that is that then they will see the full error message properly.

We can't show the error in cargo miri run since we suppress the stderr of the sysroot build to avoid clobbering the terminal.

[pnkfelix]

Why do you want to see that path?

Because I want to know where Miri is stashing intermediate state that I might have to be aware of or clean up myself

[RalfJung]

Because I want to know where Miri is stashing intermediate state that I might have to be aware of or clean up myself

I see. I think I'd prefer to cover that usecase with documentation; it seems sufficiently rare that I don't think we want to print this on every single Miri invocation. Neither cargo nor rustup print all paths they touch in their default invocation.

We can also make cargo miri run -v (verbose mode) mention the path somewhere.

[pnkfelix]

We can also make cargo miri run -v (verbose mode) mention the path somewhere.

Oh, sure, that would totally resolve my needs here.