--allow-unstable-flags: Allow unstable flags on stable#3965
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.
jyn514
added
the
T-dev-tools
|
cc some of the stakeholders:
|
There was a problem hiding this comment.
As a user and occasional contributor, I wholeheartedly support relaxation of the stability policy to provide opt-in, per-feature access to unstable features -- all unstable features, not just those that take the form of CLI flags -- on the stable toolchain.
Right now, there are several important groups of stakeholders (enumerated in this very RFC) who cannot test or experiment with unstable features, because they cannot use the nightly toolchain. There are also an unknown but probably large number of developers who will not risk using the nightly toolchain (and thus exposing themselves to all the potential breakage) even though they would like to experiment with one or two unstable features. In my opinion, therefore, the stability policy in its present state actively discourages people from testing and experimenting with unstable features, and is a major reason why it is so hard to get enough feedback to complete stabilization.
With that position in mind, a few suggested improvements to the RFC:
| To the extent that tools act as a "buffer" between feature breakage and the end-user, | ||
| they should only take responsibility for exactly the features whose breakage they know how to handle. | ||
|
|
||
| We mark language features out of scope, because we expect the new flags to reduce most of the use cases for RUSTC_BOOTSTRAP, and therefore to reduce the amount of needless cache thrashing going on. |
There was a problem hiding this comment.
Because what I care about is opening up testing and experimentation with unstable features to stakeholders who can't or won't use nightly toolchains, I would like to see this restriction lifted if at all possible. However, it would be fine with me to start with non-language features, as long as there is a path to inclusion of language features in the future. (see also below)
There was a problem hiding this comment.
👍 I think we do have that path, I discuss it a bit in "Drawbacks" under "lang features".
| We do not want to decouple our stability policy for language features, | ||
| because there's no possibility there of the library acting as a buffer between other projects and breakage[^2]. | ||
|
|
||
| [^2]: Theoretically libraries can write a build script that does feature detection, but this slows down the build for everyone, and it's very very hard to write that build script properly. |
There was a problem hiding this comment.
Feature detection should IMO be built into the language. Of course that's a big Twinkie all by itself, and I don't want to scope-creep your proposal to death. I bring it up to make clear that the current need for a difficult-to-write build script is itself a limitation that could be lifted, and therefore should not stand in the way of expanding this proposal to cover language features.
| - This may make it less likely that people help stabilize features. | ||
| But stabilizing features is [very very hard](https://medium.com/@ElizAyer/organizational-boundary-problems-too-many-cooks-or-not-enough-kitchens-2ddedc6de26a), | ||
| and in the meantime people have very little recourse when they need to use an unstable feature. |
There was a problem hiding this comment.
I believe that implementation of this proposal will actually encourage people to help stabilize features, by enabling people who can't or won't use nightly toolchains to test and experiment with unstable features. I think this possibility should be considered as a plus rather than a minus for the proposal.
There was a problem hiding this comment.
If people can't or won't use Nightly, why would they allow themselves to activate an unstable feature on Stable?
There was a problem hiding this comment.
If they activate one or two unstable features on stable, that exposes them to much less potential breakage than jumping to nightly would. It's easier to understand the risk they're taking, and presumably they have a concrete need for those unstable features (even if only curiosity) so the reward for the risk is clearer.
| Although we do not take technical measures to prevent it from being used, we strongly discourage using this feature. | ||
| If at all possible, please contribute to stabilizing the features you care about instead of bypassing the Rust project's stability policy. | ||
|
|
||
| If you do use this to enable an unstable feature, please contact a member of the project who works on the feature in question, so that we know who is exposed to breakage. |
There was a problem hiding this comment.
As I have been saying, this mechanism enables people who currently cannot to contribute to the stabilization of features. Therefore, IMO this strikes a wrong note and should be revised along the lines of "We encourage use of this mechanism, to facilitate testing and experimentation with unstable features. However, please be aware that by using it you are exposing yourself to potential breakage that your use of the stable toolchain would otherwise insulate you from. If you use this feature, please reach out to and stay in touch with a member of the project ..."
| 2. Enabling feature gates is only allowed on the nightly toolchain. | ||
|
|
||
| [^1]: There are some exceptions to this, such as https://github.com/rust-lang/rust/issues/139892#issuecomment-2808505610. | ||
| But in general we attempt to make sure all unstable features have a feature gate. |
There was a problem hiding this comment.
This line can just be cut IMO. Exception that proves the rule and all that.
| [^1]: There are some exceptions to this, such as https://github.com/rust-lang/rust/issues/139892#issuecomment-2808505610. | ||
| But in general we attempt to make sure all unstable features have a feature gate. | ||
|
|
||
| Our motivation for 1 (having feature gates) is to make sure that people do not unknowingly rely on unstable features. |
There was a problem hiding this comment.
This is missing some rationale about granularity, but that's probably not super relevant here.
| rust-analyzer and RustRover don't break at all for `--print=cfg`—they're not using it in code, only in the CLI—and adapt to any changes in libtest json format. | ||
| - These tools act as a "buffer" between other projects and breakage. | ||
| For example, semver-checks hides the breaking changes behind its own interface such that downstream projects are not affected. | ||
| Similar, RfL backports breakage fixes to stable branches such that old versions of the kernel keep building with new rust toolchains. |
There was a problem hiding this comment.
| Similar, RfL backports breakage fixes to stable branches such that old versions of the kernel keep building with new rust toolchains. | |
| Similarly, RfL backports breakage fixes to stable branches such that old versions of the kernel keep building with new rust toolchains. |
I am not sure if I understand what "buffer" means here, i.e. we do adapt and backport, but it seems this paragraph is about avoiding issues for third-party repositories. I guess it may mean that the mainline branch of Linux is the "buffer" for the stable branches? I guess it is OK, though it is the same project, so it may be a bit confusing.
Nevertheless, it is true that Rust for Linux can act as a "buffer" for others, in the sense that we do build the kernel in upstream Rust CI, and thus some issues may be found there pre-merge, and thus before they are found in other projects. On the other hand, the breakage has been fairly small so far.
There was a problem hiding this comment.
The "buffer" here is between breakage in nightly Rust and the distros that package Rust For Linux. My understanding is that they coordinate with you to determine which toolchains they can package, right? So if something breaks, you have a chance to fix it, rather than things instantly breaking on Debian Stable or whatever.
There was a problem hiding this comment.
We have an MSRV, currently the latest Debian Stable's rustc, i.e. 1.85.0, and then distributions pick whatever version they want. So e.g. Ubuntu LTS may pick 1.93.1, and that's it, i.e. they don't really see/use nightly. So I am not sure what you mean by Debian Stable breaking.
With distributions like Fedora that release packages for the latest Rust release within a few days of the release there is of course way less room, but it is still a few weeks due to the beta, and anyway we do our best to fix things while on nightly (ideally even before the PR is merged, thanks to the Rust CI building the kernel).
| - We can leave the status quo. | ||
| This is in many ways the worst of all worlds - people still use unstable features on stable, but in hacky ways that break. |
There was a problem hiding this comment.
I think the "worst of all worlds" would be the previous bullet, i.e. breaking existing projects, no? i.e. the current situation works fine in practice, after all.
Regarding "in hacky ways that break", it depends on how one looks at it: if there is no other reasonable way to do it, then it isn't really hacky! :)
| - Will this cause flags to be de-facto stable, even moreso than they are now? | ||
| We could emit a future-compat warning whenever this flag is used; is that sufficient? |
There was a problem hiding this comment.
| - Will this cause flags to be de-facto stable, even moreso than they are now? | |
| We could emit a future-compat warning whenever this flag is used; is that sufficient? | |
| - Will this cause flags to be de-facto stable, even moreso than they are now? | |
| We could emit a future-compat warning whenever this flag is used; is that sufficient? |
If a warning is emitted, it should have a way to be silenced, i.e. we don't want to "spam" end users.
There was a problem hiding this comment.
No, warning each time is intentional. I do not want people to be completely unaware that they're depending on unstable features.
There was a problem hiding this comment.
FWIW you (RfL) control Rustc's invocation, so you could (e.g.) post-process the JSON messages and filter out the ones about unstable warnings.
There was a problem hiding this comment.
No, warning each time is intentional. I do not want people to be completely unaware that they're depending on unstable features.
In that case, I cannot agree with the RFC, sorry... We cannot spam end users, distributions and other projects with warnings they cannot (and shouldn't) do anything about.
I mean, I understand that you want to prevent people from using features unaware. That is good, but if a user intentionally adds yet another flag to acknowledge the warning, then they are already aware, no? Unless you mean you want end users (rather than the developers of a project) to know about it, but then I don't understand why you would want that to begin with.
FWIW you (RfL) control Rustc's invocation, so you could (e.g.) post-process the JSON messages and filter out the ones about unstable warnings.
That sounds like a workaround to silence a warning that shouldn't be emitted to begin with since it is expected.
Generally speaking, any warning that cannot be acknowledged by a build system is likely a mistake. (My understanding is that there were rustc warnings introduced in the past that do not have a way to allow them due to how they implemented/were designed initially, but introducing more of those on purpose sounds quite bad.)
There was a problem hiding this comment.
Generally speaking, any warning that cannot be acknowledged by a build system is likely a mistake.
The problem is, again, how to distinguish a developer from a self-contained build. I don't want people just running cargo build to have unstable features hidden if they're e.g. enabled and hidden in .cargo/config.toml, which is controlled by the project, not the person running the build.
The thing I came up with was "able to post-process the output", which is true of all of RfL, semver-checks, and RA. If we get rid of that criteria and add a lint flag, then people can 1. run cargo build 2. with unstable features 3. on someone else's project they're using as a library 4. on stable 5. without ever seeing warnings. I am unwilling to accept that.
There was a problem hiding this comment.
Some experience from the --cfg tokio_unstable option we use to implement unstable features in Tokio ... for us the philosophy is that the project that decides to opt-in or not is the project that performs the final build.
So for libraries in the crates ecosystem that wish to use unstable features, they may be able to enable them locally with .cargo/config.toml, but this does not get published on crates.io, so if anyone uses that library, then the person using it from their project will have to add the same logic to their downstream .cargo/config.toml to opt-in.
I think this works well as a deterrent, and I don't think warnings are needed here.
There was a problem hiding this comment.
I don't disagree but we already have settings in Cargo.toml that aren't passed up to users of the crate as a library (eg: build.profile), so why aren't we also thinking of this as being a similar setting that is both in Cargo.toml but also doesn't float up to users of the library part of the crate?
There was a problem hiding this comment.
I don't think it's important whether it's in Cargo.toml or .cargo/config.toml as long as it has the behavior that it doesn't apply when downloaded as a library from crates.io.
There was a problem hiding this comment.
This is wandering off topic but I really want to see .cargo/config.toml stop being a thing people put in source trees (see https://internals.rust-lang.org/t/cargo-project-config-unification/24082/5 for why).
There was a problem hiding this comment.
I agree with @Darksonn's reasoning. I've moved the force-warn to "Rationale and alternatives" and out of the main RFC.
Do you mean they cannot use |
No, I mean they cannot use the nightly toolchain, which is currently the only officially sanctioned way of trying out unstable features. They could use |
That is what I mean: it is possible So that is why I was asking, i.e. those other stakeholders could, in principle, use it too. In other words, the RFC may be good idea, but it is not strictly needed in order to test those features by those stakeholders.
Using |
|
@zackw I do not understand how "Stable with an unstable feature enabled" is somehow meaningfuly different from "Nightly with the same feature enabled". Can you point to some specific non-gated instability as an example of the dangers of Nightly compared to Stable that a person would have to contend with? |
|
@Lokathor i discuss this in detail in the "motivation" section, search for "can't people just use nightly". please use threads for any further comments. |
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Miguel Ojeda <ojeda@users.noreply.github.com> Co-authored-by: DAA <42379074+DaAlbrecht@users.noreply.github.com>
jyn514
changed the title
--allow-flags: Allow unstable flags on stable--allow-unstable-flags: Allow unstable flags on stable
8 participants
View all comments
This is a follow-up to #3882 which is scoped only to CLI flags, and has improved caching mechanisms by going through Cargo.
Important
Since RFCs involve many conversations at once that can be difficult to follow, please use review comment threads on the text changes instead of direct comments on the RFC.
If you don't have a particular section of the RFC to comment on, you can click on the "Comment on this file" button on the top-right corner of the diff, to the right of the "Viewed" checkbox. This will create a separate thread even if others have commented on the file too.
Rendered