rustbuild --verbose switch is missing env var info

[pnkfelix]

When I run time python /Users/fklock/Dev/Mozilla/rust.git/x.py build --stage 1, in an error condition like error: Could not compile `core`, I see the subsequent suggestion: To learn more, run the command again with --verbose.

When I run with --verbose, I do see helpful output with the build commands it executes. In particular, I see rustc invocations that I would like to run myself, with RUST_BACKTRACE=1 turned on.

Unfortunately:

 /Users/fklock/Dev/Mozilla/rust.git/objdir-dbgopt/build/bootstrap/debug/rustc /Users/fklock/Dev/Mozilla/rust.git/src/libcore/lib.rs --crate-name core --crate-type lib -C opt-level=2 -C metadata=7824b4c14b4ca3e8 -C extra-filename=-7824b4c14b4ca3e8 --out-dir /Users/fklock/Dev/Mozilla/rust.git/objdir-dbgopt/build/x86_64-apple-darwin/stage1-std/x86_64-apple-darwin/release/deps --emit=dep-info,link --target x86_64-apple-darwin -L dependency=/Users/fklock/Dev/Mozilla/rust.git/objdir-dbgopt/build/x86_64-apple-darwin/stage1-std/x86_64-apple-darwin/release/deps
thread 'main' panicked at 'RUSTC_STAGE was not set: NotPresent', ../src/libcore/result.rs:837

i.e., the environment variable RUSTC_STAGE needs to be set. After I set that, I get:

thread 'main' panicked at 'RUSTC_SYSROOT was not set', ../src/libcore/option.rs:705

and I start to wonder: "How many of these environment variables are there? Am I going to have to deduce the values for all of them? Why doesn't the --verbose flag either include them in the command invocation output (to make it trivial to cut-and-paste the desired command), or at least include them somewhere in the output so that I can grep for them?"

[pnkfelix]

(I suspect the naive fix for this, to print key="value" each time .env is invoked within the rustbuild, is not palatable because it looks like we invoke .env many times with the same arguments for every cargo invocation.)

[pnkfelix]

cc @alexcrichton

[alexcrichton]

Yeah I've often wondered if we should update the Debug for Command implementation to print out extra environment variables. Unfortunately short of vendoring our own Command we don't really have a way to implement this in rustbuild :(

[est31]

Dupe of #38221

[pnkfelix]

I might claim that #39888 did not fix this in full generality.

Yes, the particular case where I filed this bug was one where the rustc invocation was failing, and thus --on-fail can be used to extract the state of the environment variables.

However, today I wanted to extract the rustc invocation in a case where that invocation was not failing, because I am investigating a code generation issue that I have only managed to replicate within the binary generated for rustc itself. The command I observe via --verbose does not work on its own, and I am currently assuming that this is once again due to my lack of knowledge about which environment variables to set (and to what values).

[pnkfelix]

Here's a simple diff that solves my problem completely, and I suspect is sufficiently low impact (since I think it would only affect people using RUSTC_VERBOSE=1 ... and maybe those using -vv?) that I am tempted to put it up as a PR:

diff --git HEAD:/src/bootstrap/bin/rustc.rs INDEX:/src/bootstrap/bin/rustc.rs
index 37336a56d7..182fc0862c 100644
--- HEAD:/src/bootstrap/bin/rustc.rs
+++ INDEX:/src/bootstrap/bin/rustc.rs
@@ -279,6 +279,10 @@ fn main() {
     }
 
     if verbose > 1 {
+        for (i, (k, v)) in env::vars().enumerate() {
+            eprintln!("rustc env[{}]: {} = {}", i, k, v);
+        }
+        eprintln!("rustc directory: {}", env::current_dir().unwrap().display());
         eprintln!("rustc command: {:?}", cmd);
     }

[Mark-Simulacrum]

I would be happy to review (and likely accept) such a PR.

[pnkfelix]

Reopening based on reasoning given in my earlier comment

[mark-i-m]

@pnkfelix I'm attempting to use your patch above, but I'm not sure I understand where/when those outputs would occur. I am running ./x.py build -vv. Do I need to rebuild rustc to see anything?

[pnkfelix]

@mark-i-m I would have expected the patch to cause a change to the output you saw from ./x.py build -vv, though maybe I misremember whether x.py properly rebuilds itself when the rustbuild source changes?