PSA: tracking for gated language features


I’ve recently introduced tracking issues for all feature gates (except those used privately by rustc). You can see the list here – they are the issues marked T-lang and B-unstable.

These issues will soon be referenced from the feature gates themselves. For reference, here’s the current list:

There’s not a lot of detail on most of these issues, in part because many of these features are a bit obscure and it’s not clear exactly what needs to happen prior to stabilization or removal. Please leave comments on the issues if you know more about the trajectory for a particular feature.

This effort mirrors what we did earlier with unstable library APIs, and will feed into the dashboard we publish with each week’s subteam reports. We will also use these issues to track final comment periods for feature stabilization.


Are there things you need to know here like usage? We’ve done some basic analysis of this on Servo, (and by we, I mean @Manishearth), but haven’t really put it anywhere other than internal e-mails.


Yes, hearing about usage is helpful to drive stabilization focus for some of the more niche stuff. Also, of course, any problems you’ve encountered when using these features.


@larsberg . I did forward that to some of the libs team at the time.

Note that the analysis is a few months old and some of the things there have stabilized.


By the way, is there any plans to move rustc to stable Rust? Or some kind of effort to gradually get rid of the unstable features?


We’re gradually working towards either stabilizing or deprecating unstable features; the whole point of unstable features is to gain experience with functionality we think is useful, but not ready to be stabilized.

There isn’t any effort to specifically make rustc avoid unstable features.


Yeah, I’m aware of the general effort. However, from the mention of “those used privately by rustc”, I understand that there’s some unstable features used ONLY by rustc. I think it would be nice to be able to compile rustc on stable Rust some day, so I was just wondering if those features are going to go away in the future. Not that there isn’t more important things to do first!


Well, there’s a few things which fall into this category. libcore uses miscellaneous unstable features like lang_item which are very low priority to stabilize because we expect basically everyone to use libcore. There are a few attributes related specifically to stability annotations which we can’t stabilize without breaking the stability system (like allow_internal_unstable, which lets macro expansions use unstable APIs). Compiler crates have to be marked rustc_private so people can’t use compiler internals on stable Rust.

None of this actually blocks compiling rustc on stable Rust: in theory, stage0 could build the compiler against the host’s libstd, which would allow us to side-step the complicated issues. Fixing the compiler to work against stable Rust is just a ton of work, and we’d have to give up some convenient features. (The latter category is shrinking over time.)

Short-term, I think there’s a plan to poke a hole in the stability system so stable rustc can compile rustc.