`-Zallow-features=...` on CLI is not included in `CARGO_ENCODED_RUSTFLAGS`

[mkeeter]

Problem

When passing -Zallow-features=... as a command-line flag, it is not included in CARGO_ENCODED_RUSTFLAGS. This means that build scripts which look at the encoded flags can't detect when nightly features are limited.

(This is the same type of issue as #12437, but for command-line flags instead of profile-rustflags)

Steps

I noticed this in anyhow, which reads CARGO_ENCODED_RUSTFLAGS when compiling a test program to check for nightly support.

$ cargo init anyhow-test && cd anyhow-test
$ cargo add anyhow
$ cargo check +nightly -Zallow-features=

The test program compiles successfully (because -Zallow-features= isn't propagated), so anyhow enables its nightly features, then immediately faceplants when it tries to build itself

(I initially opened anyhow#450, but agree with the author that this is a Cargo issue).

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.95.0 (f2d3ce0bd 2026-03-21)
release: 1.95.0
commit-hash: f2d3ce0bd7f24a49f8f72d9000448f8838c4e850
commit-date: 2026-03-21
host: aarch64-apple-darwin
libgit2: 1.9.2 (sys:0.20.4 vendored)
libcurl: 8.7.1 (sys:0.4.83+curl-8.15.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 3.5.4 30 Sep 2025
os: Mac OS 26.5.0 [64-bit]

[epage]

From #12437 (comment)

@weihanglo -Zallow-features is also not passed in CARGO_ENCODED_RUSTFLAGS when it specified as follows in the .cargo/config.toml:

[unstable]
allow-features = []

Is this the intended behavior? If not, I can also open a separate issue if you think it makes sense. I am running into a build problem because of it as the proc-macro2 crate enables the unstable feature proc_macro_span unless -Zallow-features is passed. As a workaround I am adding -Zallow-features to the build and target RUSTFLAGS, but that results in quite a lot of duplication as we have multiple target definitions.

From #12437 (comment)

@andreeaflorescu, your case is a bit different from this issue since unstable.allow-features is an unstable feature Cargo provides, which is a wrapper of Rustc's -Zallow-features plus Cargo its own unstable feature control. It can surely be passed in rustc as rustflags. However, it doesn't seem quite right to pass Cargo's unstable features in.

[epage]

It can surely be passed in rustc as rustflags. However, it doesn't seem quite right to pass Cargo's unstable features in.

@weihanglo I wanted to double check what you intended with this statement. Are you saying users can pass in the -Zalllow-features using RUSTFLAGS but unstable.allow-features shouldn't be appended to the users RUSTFLAGS?

[weihanglo]

Yes, because it conflates Cargo and rustc's unstable features. However I think this is also a source of confusion. Maybe we should find a way to separate them.

[epage]

What I would add is that CARGO_ENCODED_RUSTFLAGS is literally the RUSFLAGS configuration. Having Cargo add its own flags it sets based on any kind of configuration seems inappropriate.

Alternatively, Cargo could tell build scripts about allow-features more directly like we do other knowledge that Cargo has.

[epage]

I would add that build scripts automatically detecting nightly is something that at least some people in the project frown upon (and yes, anyhows maintainer is fully aware of this). I worry about us further "blessing" that workflow. On the other hand, this might provide a good way to give people control over that. If we add a build script env variable to communicate -Zallow-features to build scripts, then we could make the default be "disallow all", giving users the opportunity to opt-in to what nightly features their build scripts use. However, once we have cfg_rust_version, these nightly checks could be the only reason left to have build scripts. Granted, maybe a way to deal with that is the build script allow list mode with a static build script fallback (see #t-cargo > build script and proc macro allow list @ 💬).