[WIP] Fix: Cargo fails to detect environment variable

[LuuuXXX]

What does this PR try to resolve?

Fixes: #13280

Cargo fails to detect and rebuild while using environment variable reset environment variable which is set in config.toml.

examples:
.cargo/config.toml:

[env]
Z = "0"

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")

How should we test and review this PR?

checkout and run test:

cargo test --package cargo --test testsuite -- cargo_env_config::env_reset

Additional information

Fingerprint code is not able to detect environment variables cause they were removed from Cargo's dep-info. See #13280 (comment).

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
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

[ehuss]

I would expect this detection to be in the fingerprint code. There is code there already for managing changes in environment variables. Can you say why the current fingerprinting code is not catching this case?

[weihanglo]

@ehuss
Environment variables were removed from Cargo's dep-info because they were in rustc ProcessBuilder. See #13280 (comment).

[weihanglo]

And agree with Eric on this being fixed in fingerprint.

[LuuuXXX]

Thanks to @weihanglo for the additional explanation, it has been added to Additional information.

[LuuuXXX]

@rustbot ready

[weihanglo]

While this does fix the case described in #13280, the actual problem is not addressed: Dep-info from Cargo doesn't track # env-var: from rustc's dep-info files.

It's simple to reproduce delete the .cargo/config.toml from the case in #13280, then run

cargo r --config 'env.Z="1"'
cargo r --config 'env.Z="2"'
cargo r --config 'env.Z="3"'

Only Z=1 would be captured, and Cargo never recompile after the first invocation. Hence, the current patch just solves half of it and buries the real bug deeper.

[weihanglo]

Wonder some alternatives may be like:

• Have a set of environment variables Cargo internally sets for rustc, and removes them from Cargo's dep info here. This might need to take cargo::rustc-env build script directive into account, and I feel it will be pretty error-prone as we might miss something when adding more envs.
• Leverage the unstable --env-set rustc flag from the env sandboxing RFC. However, it is still unstable so Cargo can't use it.