Feature request: give invoked commands some indication what they are invoked as

[RalfJung]

In cargo-miri, we want to reuse as much of cargo's logic as we can, but whenever cargo invokes another binary, we want to intercept that. So we set all of RUSTC, RUSTDOC, TARGET_*_RUNNER to ourselves. The issue then becomes, when cargo calls us back, did it want rustc, rustdoc, or a binary to be run? We currently have some heuristics that do this¹, but our life would be a lot easier if cargo could set some environment variable to indicate what tool it is currently running.

An alternative might be to ship multiple binaries for these different roles, so we can set those environment variables to different values -- but that will make deployment more complicated since we'd have to figure out where to put those binaries and how to find them (currently we can just use current_exe()). Or if RUSTDOC_WRAPPER existed, possibly we could use the wrappers for everything and then if the first argument is not rustc or rustdoc, assume we must be the runner.

Footnotes

1. The heuristics would be easier if we could use RUSTC_WRAPPER, but https://github.com/rust-lang/cargo/issues/10885 and possibly also having to integrate with rustc bootstrap makes that not work, and https://github.com/rust-lang/cargo/issues/10886 makes RUSTC_WRAPPER also harder to recognize than we had expected. ↩

[RalfJung]

Oh, turns out that for TARGET_RUNNER, one actually can pass extra arguments to the binary, which we could use for disambiguation. This is causing its own problems, and AFAIK is also not possible for RUSTC and RUSTDOC.

[RalfJung]

Using --config for the runner, this issue could be resolved by making RUSTC_WRAPPER always call rustc via $WRAPPER rustc, instead of replacing rustc with the RUSTC env var (Cc #10886). It'd be even better if there also was a RUSTDOC_WRAPPER. That seems cleaner than communicating this via env vars.

EDIT: Ah, always passing rustc violates these docs. :(