Setup cargo environment for cargo rustc --print

[Veykril]

It turns out, running cargo rustc --print cfg -Zunstable-options (and the like, #9357) fail with .cargo/config.toml setups like

[build]
# custom target json that lives in `./targets/my-super-cool-target.json`
target = "my-super-cool-target"

[env]
RUST_TARGET_PATH = { value = "./targets", relative = true }

resulting in

❯ cargo rustc --print cfg -Zunstable-options
error: Error loading target specification: Could not find specification for target "my-super-cool-target". Run `rustc --print target-list` for a list of built-in targets

error: process didn't exit successfully: `C:\Users\lukas\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\bin\rustc.exe --target my-super-cool-target --print cfg` (exit code: 1)

The reason for that is that cargo recognizes the target from the .cargo/config and then implicitly passes that along to the spawned rustc process, but it does so without passing along the important environment that is required for the target tuple to make sense.

(can add a test if desired, just tell me where)

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

Dug around and not seeing other places where we miss apply_env_config

[epage]

(can add a test if desired, just tell me where)

See https://github.com/rust-lang/cargo/blob/master/tests/testsuite/rustc.rs

Looks like we have --print tests in there. Unsure about custom targets.

We generally ask that PRs are split into

• One commit that adds the test, showing the currently broken behavior (ie it passes)
• The fix commit that updates the test to pass with the change

This makes the diff between the two commits show the change in behavior

[Veykril]

Ah makes sense, will split the commit

[epage]

Forgot about a test

[epage]

Thanks!