SolvedRocket Compile with stable Rust

The following features need to be stabilized before Rocket can compile on stable:

The following dependencies rely on nightly features and must be updated before Rocket can compile on stable:

Update (Feb 07, 2017): Added list of features used by Rocket.
Update (Feb 28, 2017): Added lookup_host feature.
Update (Mar 21, 2017): pub_restricted was stabilized!
Update (Mar 30, 2017): Added never_type feature.
Update (Apr 16, 2017): Added concat_idents feature.
Update (May 19, 2017): Added struct_field_attributes and more_io_inner_methods features.
Update (May 19, 2017): concat_idents is no longer used.
Update (May 19, 2017): Added links to tracking issues.
Update (May 20, 2017): type_ascription is no longer used.
Update (Jun 19, 2017): struct_field_attributes was stabilized!
Update (Jun 24, 2017): Added try_trait feature.
Update (Jul 1, 2017): more_io_inner_methods was stabilized!
Update (Jul 9, 2017): associated_consts was stabilized!
Update (Sep 7, 2017): lookup_host is no longer used.
Update (Sep 14, 2017): drop_types_in_const was stabilized!
Update (Sep 14, 2017): Added decl_macro feature.
Update (Mar 26, 2018): conservative_impl_trait, never_type, and i128_type were stabilized!
Update (Apr 22, 2018): Added fnbox feature.
Update (Apr 26, 2018): never_type stabilization was reverted (rust-lang/rust#50121).
Update (May 5, 2018): Swapped macro_reexport for use_extern_macros.
Update (Jul 29, 2018): Added crate_visibility_modifier and try_from features.
Update (Aug 5, 2018): custom_derive is no longer used.
Update (Aug 17, 2018): use_extern_macros was stabilized!
Update (Sep 3, 2018): const_fn is no longer used.
Update (Sep 26, 2018): Added label_break_value feature.
Update (Oct 9, 2018): Removed compiler plugin features (custom_attribute, plugin).
Update (Oct 9, 2018): Updated proc_macro features.
Update (Mar 9, 2019): try_from was stabilized!
Update (Apr 13, 2019): fnbox is no longer used.
Update (Jul 9, 2019): never_type is no longer used.
Update (Jul 19, 2019): decl_macro is no longer used.
Update (Sep 9, 2019): specialization is no longer used.
Update (Sep 10, 2019): label_break_value is no longer used.
Update (Sep 18, 2019): try_trait is no longer used.
Update (Sep 21, 2019): crate_visibility_modifier is no longer used.
Update (May 19, 2020): proc_macro_hygiene was stabilized!
Update (Jul 16, 2020): proc_macro_diagnostics is no longer used.
Update (Jul 16, 2020): proc_macro_span is no longer used.
Update (Jul 21, 2020): pear was updated to be stable-compatible.

37 Answers

✔️Accepted Answer

Rocket uses much more than just plugins from nightly. The set of features Rocket currently uses are:

#![feature(plugin)]
#![feature(custom_derive)]
#![feature(custom_attribute)]
#![feature(specialization)]
#![feature(conservative_impl_trait)]
#![feature(drop_types_in_const)]
#![feature(associated_consts)]
#![feature(const_fn)]

These uses are important and contribute to the pithiness of the API, so they will stick around until they're stabilized. Until then, I don't believe Rocket will run on stable.

With that being said, I believe that the ergonomics of syntex are very poor, and I don't want to recommend a subpar solution to users. I'm all for getting Rocket to work on stable as soon as possible, but I'm not willing to compromise ergonomics and usability to make that happen.

Other Answers:

@jcbritobr the latest version of Rocket is already using Stable Rust! This is done already, that's why this issue is Closed, you are knocking on open doors. We are just waiting for the next Rocket release (0.5), because this is a breaking change.
It will be done shortly, the release depends on a couple more stuff though, compiling on Stable is just ONE of the new features, the list of the in-progress things can be found here:
https://github.com/SergioBenitez/Rocket/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.5.0

Also there's another question about the expected time of the release here: #1476
As you can see SergioBenitez commented in November that he expects an RC for 0.5 to be released by the end of the month. It's only the 1st of December, so I think we can all be a little more patient with this.

In the meantime you can use Rocket from the master branch with Stable Rust. Or maybe help with one of the ongoing issues in the Milestones section to make the release happen faster.

This is only a hispster project XD. Just for fun. I was wrong.

Chill @jcbritobr, there is no need to be [passive-]aggressive here, dude.

I understand you might be confused by the naming of the toolchains (stable vs nightly). I acknowledge they are indeed misleading.

Feel free to check the Rust release process at https://forge.rust-lang.org/release/process.html

Nightly indeed comes from the master branch and it may introduce regressions (and it sporadically does), but the nightly "instability" is not about this. Stability is about the APIs, not about the compiler introducing bugs or breaking someone's code.

If your application compiles in a specific nightly version, there should not be any problem just because it is nightly. As long as it compiles, in general, you should be safe.

— Oh, but if it runs on nightly, my build will not be reproducible and it will change every day, oh noes!

Yeah, nightly itself will change, but it is completely possible to pin a specific nightly version, e.g., 2020-11-30's nightly version! There is no need to be afraid of your toolchain changing without you knowing.

Finally, I am aware of a multitude of projects running Rocket in production. Using nightly does not make a project unstable, nor not-production-ready nor hipster as you said.

Feel free to reach out via the chat or other means if you require further clarification :)

P.S.: I am not aware of any of the contributors being paid to develop Rocket, so it is rough to impose priorities

It's been a year since this post originally... seems the check boxes in the original post are accurate?

Seems to me like getting Rocket out of nightly would be a huge boost for Rust in general but especially for Rocket.. the Rocket team or Rust team should really focus on stabilizing these functions (or finding alternatives?).

Why so slow to get there? Have you run this by the Rust higher ups and pushed them a little bit?

An IT system doesn't become "production ready" just because it has the name stable, nor does it become non-prod ready just because some component has "nightly" in its version string somewhere.

Inquiring about "when something will be done" or "why it's not done already" in a free & open source project will almost always result in someone (in this instance it's me) responding with "when someone does it" or "patches welcome".

More Issues: