RUSTC_ALLOW_UNSTABLE_<feature>: a RUSTC_BOOTSTRAP alternative
#3882
Conversation
This RFC was in large part drafted in May 2025, shortly after my Rust All Hands talk, "Futile Feature Gates". There were about 25 people in that room; I want to thank all of them for their feedback during that session, and to everyone who reviewed early drafts of this RFC.
|
tagging this as t-lang per rust-lang/leadership-council#180 (comment) |
jyn514
added
the
T-lang
BoxyUwU
added
T-compiler
|
|
||
| Our motivation for 2 (disabling feature gates on stable) is three-fold: | ||
| 1. Prevent people from relying on features that may change in the future while on the stable toolchain, upholding our "stability without stagnation" motto. | ||
| 2. Disallow library authors from "silently" opt-ing in to unstable features, such that the person running the top-level build doesn't know they're using unstable features that may break when the toolchain is updated. This rationale doesn't apply to nightly, where the party running the top-level build is assumed to know that nightly comes with no stability guarantees. |
There was a problem hiding this comment.
I think Cargo already blocks build scripts from exporting RUSTC_BOOTSTRAP.
There was a problem hiding this comment.
If we allowed feature gates on stable without what is proposed in this RFC, then Cargo can't block dependencies from using unstable features as RUSTC_BOOTSTRAP wouldn't be necessary to set.
| 2. Disallow library authors from "silently" opt-ing in to unstable features, such that the person running the top-level build doesn't know they're using unstable features that may break when the toolchain is updated. This rationale doesn't apply to nightly, where the party running the top-level build is assumed to know that nightly comes with no stability guarantees. | ||
| 3. Encourage people to help stabilize the features they care about. | ||
|
|
||
| There are some cases in which none of those goals are applicable, but we still prevent people from using nightly features. This is particularly bad when projects *must* depend on unstable features to ship another feature they care about. Some examples: |
There was a problem hiding this comment.
Another use case is tools that are built on the top of rustc. We are trying to find good solutions for that problem as we are planning on publish rustc_public, and today it either requires developers to support a specific version of nightly or export RUSTC_BOOTSTRAP. See this zulip topic for more details.
| - Enabling RUSTC_BOOTSTRAP for one part of the toolchain enables it for *all* parts of the toolchain; in particular: | ||
| - `proc-macro2` uses `cargo:rerun-on-env-changed=RUSTC_BOOTSTRAP`, causing cache thrashing whenever this env var changes. <!--Using different env variables makes it so that we only rebuild when the feature the build script actually cares about changes.--> | ||
| - rust-analyzer wants to enable RUSTC_BOOTSTRAP only for cargo and libtest, but the variable enables features for rustc as well. `RUSTFLAGS="-Z allow-features="` fixes this for lang features, but at the price of thrashing the cache; and there is no equivalent way to disable unstable CLI features. |
There was a problem hiding this comment.
How should build tools like Cargo track build cache freshness, when people can pass arbitrary RUSTC_ALLOW_UNSTABLE_<feature> environment variable between different invocation?
There was a problem hiding this comment.
RUSTC_ALLOW_UNSTABLE_<feature> can contain the name of a crate, in which case you did only need to rebuild that crate.
7 participants
This RFC was in large part drafted in May 2025, shortly after my Rust All Hands talk, "Futile Feature Gates". There were about 25 people in that room; I want to thank all of them for their feedback during that session, and everyone who reviewed early drafts of this RFC.
Rendered
Important
When responding to RFCs, try to use inline review comments (it is possible to leave an inline review comment for the entire file at the top) instead of direct comments for normal comments and keep normal comments for procedural matters like starting FCPs.
This keeps the discussion more organized.