Tracking issue for `--env-set` flag

[GuillaumeGomez]

Adds a new --env-set command line option on rustc. It allows to set environment variables value at compile-time to be used by env! and option_env! macros.

When retrieving and environment variable value, the one specified by --env-set will take precedence. For example if you want have PATH=a in your environment and pass --env-set PATH=env, then you will have:

assert_eq!(env!("PATH"), "env");

Steps

• Implement the MCP -> Done in Implement --env compiler flag (without tracked_env support) #118368, in Add support for --env on tracked_env::var #118830 and in Rename --env option flag to --env-set #119884
• Stabilization PR - Stabilize --env-set option #119926

Unresolved questions

• What is the desired behavior if the same --env variable is passed twice?

[tgross35]

Ongoing zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Stabilizing.20.60--env.60.20option.20flag.3F

[GuillaumeGomez]

We discussed about how it might impact rust-lang/rfcs#2794 and decided to rename it into --env-set to prevent potential future issues.

[fenollp]

Hi! I see the stabilization PR was closed. What's the state of this then?

My 2cents on a couple points:

• I need this so my $RUSTC_WRAPPER knows which envs to forward to rustc. Can't just forward all the envs.
• same keys in duplicate --env-set KEY=.. should be an error. It resolves that point and allows forward compatibility

If help is needed here I'd like to provide some!

[xclaesse]

Hi, is there anything preventing this to be stabilized? It's pretty important as ninja cannot set env when running rustc commands. It makes using rustc outside of cargo (e.g. Meson) harder.