--env-set interaction with the compiler itself

The first attempt at stabilizing --env-set (#118372) in #119926 was blocked by a concern (#119926 (comment)):

I wonder how should all of them interact with --set-env.
Never interact? Always interact? Interact on a case-by-case basis?

I.e. should --env-set PATH=. have a impact on where rustc would search the linker and other tools that the compiler may use, or if it should be restricted to the Rust code it-self: env!, option_env!, ... as it's currently the case ?

For reference the current documentation: https://doc.rust-lang.org/beta/unstable-book/compiler-flags/env-set.html

@fenollp

@fenollp @xclaesse @dblsaiko @bonzini (cc-ing you since expressed interest in the feature before) could you share your opinion on the blocker to stabilization.

Even after stabilization it wouldn't be applicable for some time to procedural macros (because they currently use std::env and proc_macro::tracked::env_var is not stable, which is a chicken-and-egg situation); also, it doesn't apply to build.rs files that compute the env var's name, because of the difference between env! and env::var.

These may not be huge issues (proc macros that read environment variables are relatively rare, and e.g. meson doesn't use build.rs at all), but there are some high profile cases like proc_macro_crate; and overall, they make the feature unortogonal.

I think it should be considered a failed experiment.

it doesn't apply to build.rs files that compute the env var's name, because of the difference between env! and env::var.

Yeah, that's the difference between compile-time and runtime-time environment variables. The compiler can't do anything about runtime envs.

Even after stabilization it wouldn't be applicable for some time to procedural macros

As you said it, it a chicken-and-egg situation, we have to start somewhere, and I'm sure we can push #99515 forward as well.

but there are some high profile cases like proc_macro_crate

I'm not familar with the issues regarding this crate, could you explain them?

I think it should be considered a failed experiment.

How does mesonbuild/meson#15148 fall into this? Are you expecting mesonbuild/meson#15148 to reverted?

I'm not familar with the issues regarding this crate, could you explain them?

It's an example of the chicken and egg situation.

How does mesonbuild/meson#15148 fall into this? Are you expecting mesonbuild/meson#15148 to reverted?

There is work in progress to use a wrapper program to invoke rustc with environment variables on Windows, at this point --env-set would be unnecessary. It is only used in connection with experimental parts of meson anyway.

@dtolnay

@dtolnay I see that buck2 is also using --env-set in some places.

As per above meson doesn't seems to be needed it anymore, what about buck2?

Buck does not pass --env-set to rustc, they are intercepted here.

Thanks everyone for the feedback. There doesn't to be a future for the feature. I will propose removing it.

Rollup merge of rust-lang#161831 - Urgau:rm-env-set, r=nnethercote

Unrolled build for #161831 in rollup 162035

Rollup merge of #161831 - Urgau:rm-env-set, r=nnethercote

Navigation Menu

Repository navigation

`--env-set` interaction with the compiler itself #161609

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

--env-set interaction with the compiler itself #161609

Description

Activity

Urgau commented on Aug 23, 2026

bonzini commented on Aug 23, 2026

Urgau commented on Aug 24, 2026

bonzini commented on Aug 24, 2026

Urgau commented on Aug 24, 2026

dtolnay commented on Aug 24, 2026

Urgau commented on Aug 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`--env-set` interaction with the compiler itself #161609