Cargo fails to detect environment variable is newly set and rebuild if the environment variable is set in `config.toml`

[usamoi]

Problem

The problem can be only reproduced if the environment variable is "not set" in the first run, and "set" in the second run.

Steps

Incorrect behaivor

.cargo/config.toml:

[env]
Z = "0"

src/main.rs:

fn main() {
    println!("{:?}", option_env!("Z"));
}

run these commands:

cargo run     # first build, output Some("0")
Z=1 cargo run # cargo does not notice the environment variable is set and runs it, output Some("0")

Correct behaivor if we do not use a config.toml

src/main.rs:

fn main() {
    println!("{:?}", option_env!("Z"));
}

run these commands:

cargo run     # first build, output None
Z=1 cargo run # cargo does know the environment variable is set and rebuilds it, output Some("1")

Correct behaivor if we change the environment variable from a value to another value

.cargo/config.toml:

[env]
Z = "0"

src/main.rs:

fn main() {
    println!("{:?}", option_env!("Z"));
}

run these commands:

Z=2 cargo run # first build, output Some("2")
Z=1 cargo run # cargo does know the environment variable changes and rebuilds it, output Some("1")

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.77.0-nightly (ac6bbb332 2023-12-26)
cargo 1.75.0 (1d8b05cdd 2023-11-20)

[heisen-li]

By the way, it may be related to question #10358 & #12434.

[weihanglo]

By the way, it may be related to question #10358 & #12434.

Hmm… I don't quite think so. It is related to cargo's own dep-info file failed to track env vars from [env] table. Cargo removes those here:

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

Lines 2017 to 2019 in 0c98d6e

	on_disk_info
	.env
	.retain(|(key, _)| !rustc_cmd.get_envs().contains_key(key) || key == CARGO_ENV);

env vars from [env] were applied to rustc_cmd in fill_env() earlier before this call.

[weihanglo]

Note: #13596 was an attempt of addressing this issue. In that PR, maintainers expected that kind of environment variable detection to be in the fingerprint code, where Cargo's dep-info logic is located.

[weihanglo]

#14154 is another case that Cargo's depinfo strips internal set environment variables (such as CARGO_PKG_README) causing the rebuild detection failure.