First, some context. I recently landed an unstable feature in cargo:
-Zpatch-in-config (tracking issue) which allows
[patch] sections to appear in
.cargo/config files. This particular feature would significantly improve developer ergonomics in a larger build system I'm working with that "wraps" cargo in the context of a much larger build process.
Now that this feature is in the nightly compiler, the next step is to work towards stabilization, much of which consists on getting feedback on how well the feature works. However, this is where I run into an issue — while I have the opportunity to test the feature at a fairly large scale by using it in said build system, I cannot currently do so in a reasonable way. I must either switch the build system to use a nightly version of cargo/rustc, or use
RUSTC_BOOTSTRAP=1 on stable/beta, both of which enable all unstable features. In the context of this build system, that's not okay, as it would enable all the developers that use said build system to start using any unstable features they'd like without any additional safe-guards.
I think this gets at a broader point that currently it's very difficult to get large-scale testing of an unstable feature, because any users that may be in a position to test at a large scale are likely unable or unwilling to deploy a nightly compiler or open the flood-gates of all unstable features with
What I'd like to see is a mechanism to enable just a particular set of unstable features, and no others, so that users can beta-test specific features without having to test all the other features at the same time. This is probably primarily useful in the context of custom build systems that wish to test-deploy a change across a larger package repository, though there may also be other use-cases I haven't thought of.
As for the exact mechanism, I'd propose a new environment variable
RUST_ONLY_ALLOW_FEATURES that takes a comma-separated list of unstable features to allow. For example:
env RUST_ONLY_ALLOW_FEATURES="cargo:patch-in-config,rustc:sanitizer,rustc:doc-cfg" cargo
- It makes it difficult for crate authors to depend on this kind of selective enabling, which discourages its use, just like for
- It enables the feature to span both
- It aligns the feature closely with
RUSTC_BOOTSTRAPas a mechanism that should be used sparingly
Anecdotally I'll add that this particular environment variable is likely to be used in conjunction with
RUSTC_BOOTSTRAP=1 so that larger organizations can help beta-test a particular feature (or set of features) without subjecting themselves to the instability of
This feature is tangentially related to some previous discussions on internals.r-l.o:
though takes a slightly different approach. Rather than constructing another mechanism for opting into unstable features, it paves the path for using the existing mechanism,
RUSTC_BOOTSTRAP=1, and making it safer to use by restricting what setting
RUSTC_BOOTSTRAP actually enables.
This kind of change would almost certainly need to go through an RFC, but I figured I'd post it here for some initial feedback.