Compile with stable Rust

[SergioBenitez]

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

• never_type (rust-lang/rust#35121)
• proc_macro_hygiene (rust-lang/rust#54727)
• decl_macro (rust-lang/rust#39412)
• proc_macro_diagnostics (rust-lang/rust#54140)
• proc_macro_span (rust-lang/rust#54725)
• associated_consts (rust-lang/rust#29646)
• conservative_impl_trait (rust-lang/rust#34511)
• drop_types_in_const (rust-lang/rust#33156)
• more_io_inner_methods (rust-lang/rust#41519)
• pub_restricted (rust-lang/rust#32409)
• struct_field_attributes (rust-lang/rust#41681)
• use_extern_macros (rust-lang/rust#35896)

The following features are currently used by Rocket but do not need to be stabilized before Rocket can compile on stable because their use in Rocket can somewhat easily be removed:

• try_trait (rust-lang/rust#42327)
• specialization (rust-lang/rust#31844)
• fnbox (rust-lang/rust#28796)
• crate_visibility_modifier (rust-lang/rust#45388)
• try_from (rust-lang/rust#33417)
• label_break_value (rust-lang/rust#48594)

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!

[steveklabnik]

Looks like this primarily depends on rust-lang/rust#38356

(Or syntex)

[rrichardson]

Syntex should get this onto stable much more quickly, since the macros > 1.1 effort seems to be just beginning to congeal.

https://news.ycombinator.com/item?id=13245975

[steveklabnik]

since the macros > 1.1 effort seems to be just beginning to congeal.

This needs more than macros 1.1, it needs 2.0. (If it only needed 1.1, then it could go stable in 1.15)

[rrichardson]

I intended > 1.1 to indicate "after 1.1" but that wasn't very clear.
I've seen the procedural macros effect referenced as 1.2 as well as 2.0. 2.0 does make more sense, since it is a much broader scope, as I understand it.

[mgattozzi]

I've started working on getting syntex to work with this until macros are stabilized (which might be a while). I've got time over the holidays from work so I'll post any progress I make!

[SergioBenitez]

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.

[beefsack]

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.

I'd love to see it go stable as soon as possible, but I feel you've got the right values for the project. Accessibility is arguably more important for web frameworks than it is for other frameworks and libraries.

[mgattozzi]

Just from trying to get it to work with syntex it's hard. I might try some more this week but you're right. It might just be worth it to wait till those features stabilize.

[tbu-]

The lookup_host feature can be replaced by the ToSocketAddrs implementation of &str.

[FractalMatt]

Perhaps you could use something like:
https://github.com/Kimundi/rustc-version-rs

In order to allow stable features to compile using stable, but features that require nightly or beta could be used only when compiling from that branch.

Currently using Iron myself and would love to switch but it's a high security project and for security reasons, I want to avoid Rust nightly.

[FractalMatt]

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?

[est31]

i128 just got stabilized will ship in Rust 1.27.0.

[tsal]

I'm really looking forward to using Rocket in production some day, I'm glad to see there's been some progress recently. :)

[messense]

macro_reexport is now removed(not in nightly yet, incoming breaking change) and subsumed by feature(use_extern_macros) and pub use

rust-lang/rust#49982

[maxdeviant]

@messense PR #624 should handle those changes.

[mentalbrew]

The Rust community is currently in a major push toward releasing the Rust 2018 Edition. Has anybody investigated whether enough features that Rocket depends on in nightly will be available in that edition that the Rocket community could target that release for stable? It seems like it would be a win-win for both efforts if it was remotely feasible.

[jebrosen]

I glanced at the 2018 feature status and most of the important ones for Rocket are not listed:

• const_fn
• decl_macro
• never_type
• proc_macro, and several related features such as proc_macro_non_items
• specialization, which can apparently be worked around, but might be problematic to drop for existing rocket users

That does not necessarily mean that these features will not be stabilized this year, just that they are not being targeted as part of the Edition. async/await, however, is listed, and says 2018 will be the minimum edition. Depending on what async solution is implemented, Rocket might target the 2018 edition to make use of those ergonomics.

That being said, editions are cross-crate compatible. Whether Rocket ends up targeting the 2015 or 2018 edition should not significantly affect projects that use it.

[est31]

Just noting, proc_macro is in the process of being stabilized: rust-lang/rust#52081

[SergioBenitez]

@est31 Unfortunately, the stabilizing subset is extremely limited and insufficient for Rocket's needs.

[cauebs]

Now there's an easier way to keep track of these things: https://forge.rust-lang.org/state-of-rust.html

[bestouff]

Either way it'd be nice to have a "tentative ETA" for stable Rocket. Even if it's "don't expect less than 2 years" that could help a lot people who might want to select it but wonder about how long they have to suffer in nightly.

[FractalMatt]

@SergioBenitez You should really reach out to the Rust team and ask for them to prioritize these issues, tell them it's holding up release of Rocket. Or maybe someone can volunteer to help fix these issues if they'll help point you in the right direction?

I know that getting Rocket-like web servers was being listed as a high priority for getting Rust adoption and Rocket looks like an otherwise amazing one.

Team can be found here:
https://www.rust-lang.org/en-US/team.html

Have communicated with Brian in the past who seemed particularly good at responding and helping us out on a far less important issue:
https://github.com/brson

[0xcaff]

FYI, if you don't want to wait to build web services in rust, check out actix. It works on stable rust.

[dataf3l]

@0xcaff After trying multiple web frameworks, I have to say really like Rocket.
Iron, unfortunately, didn't do it for me...

I'm grateful for the efforts made by the iron team, and I value open source contributor's time as much as the next guy, but for me, I think Rocket suits fits my needs better.

[ErichDonGubler]

proc_macro has been split into several subtasks -- which one(s) does Rocket depend on?

EDIT: Thanks!

[Xaeroxe]

The following workaround has been used by the Amethyst game engine for the absence of a never type

pub enum Never {}

This type can't be instantiated and thus fills the same purpose.

[BanjoFox]

Very happy to see this progressing!
Team Aardwolf appreciates your hard work :D

[jhpratt]

Given the recent blogpost, shouldn't the milestone on this be 0.5?

[est31]

@incubus8 see this blog post for details on the plans: https://rocket.rs/v0.4/news/2018-12-08-version-0.4/

[incubus8]

gotcha, sorry for the fuzz

@incubus8 see this blog post for details on the plans: https://rocket.rs/v0.4/news/2018-12-08-version-0.4/

[macpp]

Just noting: on the latest nightly uniform_paths were stabilised, together with ability to export macro_rules from modules:

mod foo {
    macro_rules! bar123 { () => {} }
    pub(crate) use bar123 as bar;
}
foo::bar!();

It seems that it may be possible to remove decl_macro feature ( when targeting 2018 edition)

[jebrosen]

It seems that it may be possible to remove decl_macro feature ( when targeting 2018 edition)

I played with the new export functionality you mention; it's unfortunate that it only works when the application crate targets 2018. I think it would be acceptable to implement the change if 2018 is required for another reason (e.g. async/await). But I wouldn't want to break compatibility with 2015 edition just to avoid decl_macro unless it's the only feature blocking stable, and maybe not even then.

[Centril]

@jebrosen I would suggest avoiding long term reliance on decl_macro; I don't think the language team has any bandwidth to devote the substantial time that decl_macro requires to stabilize it.