`cargo:rerun-if-env-changed` doesn't work with `env` configuration

[bsilver8192]

Problem

When a build.rs script emits cargo:rerun-if-env-changed, it is not re-run when the value of the specified variable is changed via the env configuration.

Steps

build.rs:

pub fn main() {
    println!("cargo:rerun-if-env-changed=FOO");
    if let Ok(foo) = std::env::var("FOO") {
        assert!(&foo != "bad");
    }
}

.cargo/config.toml:

[env]
FOO = "good"

1. Run cargo build, it succeeds.
2. Change .cargo/config.toml to this:

[env]
FOO = "bad"

3. Run cargo build again, and it uses the cached build and succeeds. It should run build.rs again, and it should fail.

Workaround

4. Run FOO=bar cargo build, ignore the result.
5. Run cargo build again, now it runs build.rs with FOO=bad from the config and fails as expected.

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.58.0 (7f08ace4f 2021-11-24)
release: 1.58.0
commit-hash: 7f08ace4f1305de7f3b1b0e2f765911957226bd4
commit-date: 2021-11-24
host: x86_64-unknown-linux-gnu
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1l)
os: Debian 11 (bullseye) [64-bit]

[weihanglo]

This is somehow similar to #10094. Cargo does not take into account the new configurable-env when calculating local fingerprint of rerun-if-env-changed.

cargo/src/cargo/core/compiler/fingerprint.rs

Lines 1571 to 1577 in 07e9d46

	for var in deps.rerun_if_env_changed.iter() {
	let val = env::var(var).ok();
	local.push(LocalFingerprint::RerunIfEnvChanged {
	var: var.clone(),
	val,
	});
	}

When dealing with this issue, perhaps we should consider corner cases mentioned it this comment as well.

[therealfrauholle]

To share my experience: This is a really nasty bug. We finally found this issue and are now aware of it, but we actually faced this issue often in the past, e.g. when configuring logging levels by the [env] section. It caused us a lot of pain since it is so subtle, yet has impact on what is actually compiled.

Looks like a small thing, but should be of high priority, I think - maybe add a warning?

[bczhc]

+1. Kept debugging and debugging, just to end up finding this issue. Cargo doesn't compile with the right envs as the configuration file writes, quite annoying and tricky...

[weihanglo]

If I understand correctly, this shares the same root cause with #12434. Just two different ways to get hurt by the bug.

[weihanglo]

Copying my comment in #12434 (comment):

We should perhaps switch from std::env::var to Config::get_env and Config::env_config.

cargo/src/cargo/core/compiler/fingerprint/mod.rs

Lines 776 to 784 in 3a34fca

	// TODO: This is allowed at this moment. Should figure out if it makes
	// sense if permitting to read env from the config system.
	#[allow(clippy::disallowed_methods)]
	fn from_env<K: AsRef<str>>(key: K) -> LocalFingerprint {
	let key = key.as_ref();
	let var = key.to_owned();
	let val = env::var(key).ok();
	LocalFingerprint::RerunIfEnvChanged { var, val }
	}

However, there are at least two hard things needing to consider.

• Environment variables in [env] can be “config-relative”. Should we hash the absolute path into local fingerprint? That seems to be the correct behavior, but it might also hurt the cache sharing story when a user has changed the project root path.
• To resolve config-relative paths to absolute, we need Config. However rerun-if-env-changed is computed within a unit of work Cargo spawned. The unit of work is executed in a multi-thread context so Config cannot be easily shared. The code might need a relative large overhual to make it work.