[env] settings are not consistently applied to rustc invocations

[main--]

Problem

The docs on the [env] section in the config file state:

The [env] section allows you to set additional environment variables for build scripts, rustc invocations, cargo run and cargo build.

Hence, I would expect these variables to be set whenever rustc is invoked. In practice, compiling a simple Hello World crate reveals that the compilation starts with a rustc invocation that does not have these environment variables set.

Steps

1. Set an environment variable in the cargo config
2. Expect it to consistently apply to all rustc invocations
3. It doesn't

Possible Solution(s)

The environment variable should be consistently applied to all rustc invocations.

Notes

This problem is especially frustrating in conjunction with sccache (as rustc-wrapper). sccache can be configured via environment variables, which makes an [env] section in a config.toml an extremely attractive way for a project-specific caching setup. sccache launches a server process on its first invocation. Since the current behavior of cargo is to ignore environment variables for the first rustc invocation, sccache will at that point launch a server process that is missing the config (and instead defaults to caching on the local disk). Subsequent invocations would have the environment variables present, but since the sccache server is already running, they will be ignored. In essence, the only way to make this work is to wrap sccache in a shell script that explicitly sets the variables, rendering cargo's env feature entirely useless for this usecase.

Version

cargo 1.68.0 (115f34552 2023-02-26)
release: 1.68.0
commit-hash: 115f34552518a2f9b96d740192addbac1271e7e6
commit-date: 2023-02-26
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:OpenSSL/1.1.1q)
os: Arch Linux Rolling Release [64-bit]

[epage]

Can you give more detailed reproduction steps?

I setup a project

$ cargo init
$ mkdir .cargo

.cargo/config.toml

[env]
HELLO="goodbye"

src/main.rs

fn main() {
    println!("{}, world!", env!("HELLO"));
}

And got this result:

$ cargo run
   Compiling cargo-12028 v0.1.0 (/home/epage/src/personal/dump/cargo-12028)
    Finished dev [unoptimized + debuginfo] target(s) in 0.44s
     Running `target/debug/cargo-12028`
goodbye, world!

[main--]

Sure!

$ cargo init
$ mkdir .cargo
$ cat > .cargo/config.toml
[build]
rustc-wrapper = './wrapper.sh'

[env]
HELLO="goodbye"
$ cat > wrapper.sh
#!/bin/sh
echo "HELLO=$HELLO" >> build.log
exec "$@"
$ chmod +x wrapper.sh
$ cargo build
$ cat build.log
HELLO=
HELLO=goodbye

This problem is especially obnoxious to debug because the output of the env-less invocation is totally suppressed, so it only becomes visible by writing into a file.

[ehuss]

@epage They are referring to the target discovery (around here). I think it was just an oversight.

[weihanglo]

To make [env] work for the rustc invocation of the target discovery, we could apply code similar to this:

cargo/src/cargo/core/compiler/compilation.rs

Lines 352 to 362 in a4a8bd1

	// Apply any environment variables from the config
	for (key, value) in self.config.env_config()?.iter() {
	// never override a value that has already been set by cargo
	if cmd.get_envs().contains_key(key) {
	continue;
	}
	if value.is_force() || self.config.get_env_os(key).is_none() {
	cmd.env(key, value.resolve(self.config));
	}
	}

Could it be that people already depend on this unfortunate oversight that first rustc call get no env from [env]? Feel like it's pretty rare.