RUSTFLAGS in [env] section in .cargo/config.toml is silently ignored

[orlp]

Create a new project (cargo new foo), edit .cargo/config.toml and add:

[env]
RUSTFLAGS = "-C opt-level=illegal"

I expected to see this happen:

• Either a correct passing of the RUSTFLAGS leading to an error:

  error: optimization level needs to be between 0-3, s or z (instead was `illegal`)
  

• Or alternatively a warning that RUSTFLAGS is ignored in the [env] section, and that it must be passed with the rustflags option in either [build] or [target].

Instead, this happened:

• Build silently succeeds, ignoring the set RUSTFLAGS entirely.

Meta

rustc --version --verbose:

rustc 1.94.0-nightly (7b5cde737 2025-12-27)
binary: rustc
commit-hash: 7b5cde7370b82fecf700071dda98c3fbc7d41fae
commit-date: 2025-12-27
host: aarch64-apple-darwin
release: 1.94.0-nightly
LLVM version: 21.1.8

[bjorn3]

If I understand correctly [env] doesn't modify the environment of cargo itself, but rather the environment of programs cargo spawns, so your env.RUSTFLAGS would result in rustc getting RUSTFLAGS added to its environment rather than passed as cli flags.

@rustbot transfer cargo

[weihanglo]

If I understand correctly [env] doesn't modify the environment of cargo itself, but rather the environment of programs cargo spawns, so your env.RUSTFLAGS would result in rustc getting RUSTFLAGS added to its environment rather than passed as cli flags.

That is correct. If you are able to set env.RUSTFLAGS, you should be able to set build.rustflags in config which is a better choice.

That said, the current doc is unclear and ambiguous:

The [env] section allows you to set additional environment variables for build scripts, rustc invocations, cargo run and cargo build.

@rustbot label +A-documenting-cargo-itself +S-needs-design

[rustbot]

Error: Parsing relabel command in comment failed: ...'s-design -' | error: empty label at >| '

'...

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

[epage]

This is a downside of some cargo env variables not being prefixed with CARGO_: it isn't obvious what is the intended consumer, cargo, rustc, or something else.