Add the ability to completely disable experimental features in release channels #16678
Comments
|
Some notes from @alexcrichton about potential next steps
|
|
If I understand this right, Servo won't be compilable with release compiler? That seems unfortunate. Has anyone done a survey to see how many projects are in the same boat? |
|
Servo should use the unstable channel of Rust, by design; Servo is still a research project and it's helping to experiment with unfinished parts of the language. Over time, as Servo matures and becomes a shipping product, it should switch to release channel, because it -- like any production software -- should be basing itself on more highly QA'ed features and not be shipping with experimental language features. The nice thing about the train model is that experimental features can stabilize and land faster than they do in traditional languages since they aren't blocked on unrelated features, and trains run regularly frequently. In general, the reason for not making experimental features available to release channel is the same as not allowing them in release browsers (note that prefs are a per-user switch, not a per-developer switch, and this is the key distinction): if we allowed people to ship using experimental features, we'd've lost all the ability to clearly message that they are experimental and will change. The channels are our strongest, clearest source of messaging what comes with a guarantee of stability and what does not. If we allowed people to opt out, we'd have no levers left to make it possible to ship experimental features without them getting prematurely frozen. And we'd lose the ability to guarantee that successfully compiling with Rust 1.0 means successfully compiling with Rust 1.1. In other words, it would jeopardize both the ability to experiment and the ability to guarantee stability. |
|
Another way to look at this: the release channel is the channel for production users. If most people are using the unstable channel when 1.0 first comes out, that's just fine. We're preparing for production users but it'll take time for that set to grow. :) |
pnkfelix
changed the title
|
cc #17895 |
This partially implements the feature staging described in the [release channel RFC][rc]. It does not yet fully conform to the RFC as written, but does accomplish its goals sufficiently for the 1.0 alpha release. It has three primary user-visible effects: * On the nightly channel, use of unstable APIs generates a warning. * On the beta channel, use of unstable APIs generates a warning. * On the beta channel, use of feature gates generates a warning. Code that does not trigger these warnings is considered 'stable', modulo pre-1.0 bugs. Disabling the warnings for unstable APIs continues to be done in the existing (i.e. old) style, via `#[allow(...)]`, not that specified in the RFC. I deem this marginally acceptable since any code that must do this is not using the stable dialect of Rust. Use of feature gates is itself gated with the new 'unstable_features' lint, on nightly set to 'allow', and on beta 'warn'. The attribute scheme used here corresponds to an older version of the RFC, with the `#[staged_api]` crate attribute toggling the staging behavior of the stability attributes, but the user impact is only in-tree so I'm not concerned about having to make design changes later (and I may ultimately prefer the scheme here after all, with the `#[staged_api]` crate attribute). Since the Rust codebase itself makes use of unstable features the compiler and build system to a midly elaborate dance to allow it to bootstrap while disobeying these lints (which would otherwise be errors because Rust builds with `-D warnings`). This patch includes one significant hack that causes a regression. Because the `format_args!` macro emits calls to unstable APIs it would trigger the lint. I added a hack to the lint to make it not trigger, but this in turn causes arguments to `println!` not to be checked for feature gates. I don't presently understand macro expansion well enough to fix. This is bug rust-lang#20661. Closes rust-lang#16678 [rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
This partially implements the feature staging described in the [release channel RFC][rc]. It does not yet fully conform to the RFC as written, but does accomplish its goals sufficiently for the 1.0 alpha release. It has three primary user-visible effects: * On the nightly channel, use of unstable APIs generates a warning. * On the beta channel, use of unstable APIs generates a warning. * On the beta channel, use of feature gates generates a warning. Code that does not trigger these warnings is considered 'stable', modulo pre-1.0 bugs. Disabling the warnings for unstable APIs continues to be done in the existing (i.e. old) style, via `#[allow(...)]`, not that specified in the RFC. I deem this marginally acceptable since any code that must do this is not using the stable dialect of Rust. Use of feature gates is itself gated with the new 'unstable_features' lint, on nightly set to 'allow', and on beta 'warn'. The attribute scheme used here corresponds to an older version of the RFC, with the `#[staged_api]` crate attribute toggling the staging behavior of the stability attributes, but the user impact is only in-tree so I'm not concerned about having to make design changes later (and I may ultimately prefer the scheme here after all, with the `#[staged_api]` crate attribute). Since the Rust codebase itself makes use of unstable features the compiler and build system do a midly elaborate dance to allow it to bootstrap while disobeying these lints (which would otherwise be errors because Rust builds with `-D warnings`). This patch includes one significant hack that causes a regression. Because the `format_args!` macro emits calls to unstable APIs it would trigger the lint. I added a hack to the lint to make it not trigger, but this in turn causes arguments to `println!` not to be checked for feature gates. I don't presently understand macro expansion well enough to fix. This is bug rust-lang#20661. Closes rust-lang#16678 [rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md Next steps are to disable the existing out-of-tree behavior for stability attributes, and convert the remaining system to be feature-based per the RFC. During the first beta cycle we will set these lints to 'forbid'.
fix: panic when inlining callsites inside macros' parameters Close rust-lang#16660, rust-lang#12429, rust-lang#10695. When `inline_into_callers` encounters callsites in macros parameters, it can lead to panics. Since there is no perfect way to handle macros, this PR directly filters out these cases.
In the stable release channel we're probably going to completely disable the ability to use experimental features and libraries. Add this capability to the build.
cc #16677
The text was updated successfully, but these errors were encountered: