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:

pear (SergioBenitez/Pear@333c9bf)

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.

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

(Or syntex)

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

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)

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.

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!

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.

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.

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.

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

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.

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?

~~never_type will be stabilized in Rust 1.26.0.~~

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".

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

@jcbritobr

@jcbritobr, in the chat people are talking about the next release that is coming soon. So if we are a little bit patient, everything is fine.

@jcbritobr

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

@jcbritobr

@jcbritobr, in the chat people are talking about the next release that is coming soon. So if we are a little bit patient, everything is fine.

Hello. I'm not being passive/agressive. Look up these answers above. I only think bugs and stability comes first of new features. Postpone rocket on stable rust doesn't seems to be an intelligent decision. Nightly rust isn't stable rust, but if you guys think so very well. For me, its a hispter atitude. Just like for fun. Nothing to really help or agreggate the project.

@jcbritobr

@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.

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.

I kind of understand your point, but the reality is that that point of view is not widely shared, or even considered. The nomenclature is no doubt intended to have semantic meaning, and packaging crew working on numerous linux and BSD distributions see it exactly this way (i.e. nightly is not intended for production). For somebody trying to get projects based on rocket into packages destined for various distributions this is a significant hurdle. I've had this problem with Alpine Linux and with OpenBSD just this month.

For somebody trying to get projects based on rocket into packages destined for various distributions this is a significant hurdle.

Could you give examples of those projects?

I've had this problem with Alpine Linux and with OpenBSD just this month.

Are many people using those projects with OpenBSD? OpenBSD is a very security-focused project, it's conservative in its scope, prefers simple instead of fast and fancy. If the OpenBSD maintainers feel they don't want to take something in then they'll keep coming up with excuses anyway. (Packaging policies are "premade excuses", they are not a guarantee for inclusion.)

So, even if that view is not shared, then I think a simpler version of that is probably applies here, which is even if something is "stable" it doesn't make it production ready. (Bugs happen. Ensuring quality is a process, determining fitness for a purpose requires a deliberation by someone who understands the needs and requirements of that purpose. A simple version sticker will never be able to do that.)

That said I completely understand distros' problem with managing "nightly", as it means an endless stream of packages. (Thus busy work.) It takes up space, it bloats the repository metadata, etc, etc. The solution is probably for those projects that depend on Rocket to do the packaging themselves and offer a repo that users can add, or a setup/update script. (I have no idea how that works on OpenBSD though. For Alpine it's pretty straightforward to host a repo, put APKs there and for users to set it up via /etc/apk/repositories and /etc/apk/keys .)

I think the main problem for OpenBSD is that the package manager provide the latest stable, but not the nightly rust. Thus, you'll have to compile the compiler yourself if you want nightly as the rust project do not distribute rust for OpenBSD.

Note that, as a workaround, you can use a stable compiler with RUSTC_BOOTSTRAP=1, and I think you'll have a rustc with feature gates usable.

@TeXitoi

@TeXitoi please don't do that outside of local testing. It will cause issues the moment the compiler is updated.

Could you give examples of those projects?

The best example in my opinion is bitwarden_rs. It is quite a popular project and seems to be increasingly so.

Are many people using those projects with OpenBSD? OpenBSD is a very security-focused project, it's conservative in its scope, prefers simple instead of fast and fancy. If the OpenBSD maintainers feel they don't want to take something in then they'll keep coming up with excuses anyway. (Packaging policies are "premade excuses", they are not a guarantee for inclusion.)

Since the packages don't yet exist officially or via contrib as far as I know, I don't have a clear signal how who is using them on those platforms. I personally believe there is latent demand for them. I myself am trying to package them because I want to use them.

I admit I don't know if they will accept a package before I present it, and the reason they fail to be accepted I don't always agree with but even for my own use I still prefer the formal packaging system, and in the past I have experienced maintaining it this way it may eventually get accepted. My personal experiences with OpenBSD have been more positive, I suspect, based on your view expressed here.

So, even if that view is not shared, then I think a simpler version of that is probably applies here, which is even if something is "stable" it doesn't make it production ready. (Bugs happen. Ensuring quality is a process, determining fitness for a purpose requires a deliberation by someone who understands the needs and requirements of that purpose. A simple version sticker will never be able to do that.)

I can see how this is true but is it really useful or good advice or a packagist? The fact is that stable, nightly and packaging policies are all systems to try to distill very complex things down to abstractions about which you can try to make reasonable decisions about. You're not claiming that nightly is just as stable as stable. It probably isn't on the whole. For a packagist trying to make the best decisions to further the interests of their chosen distribution, and probably with only casual knowledge about he myriad things over which they have purview, they will resort to leaning on these abstractions and for the most part that is completely reasonable and understandable.

That said I completely understand distros' problem with managing "nightly", as it means an endless stream of packages. (Thus busy work.) It takes up space, it bloats the repository metadata, etc, etc.

Absolutely. All good reasons that many will just want to keep it simple and stick with stable.

The solution is probably for those projects that depend on Rocket to do the packaging themselves and offer a repo that users can add, or a setup/update script. (I have no idea how that works on OpenBSD though. For Alpine it's pretty straightforward to host a repo, put APKs there and for users to set it up via /etc/apk/repositories and /etc/apk/keys .)

Yes, and no doubt some will choose to do that, but many projects will not be able to cover all that ground and there are packagists willing to do some of that lifting. Sticking with stable immediately lowers the bar for them, from a complexity point of view and from a distribution policy point of view. Neither of the challenges are insurmountable or even significant, but it is friction none the less.

In summary, all I argue is that relying on stable has more significant upside for rocket and projects that depend on it than I think has been acknowledged so far in this thread. I personally think rocket has a bright future and I'm looking forward to using it more myself.

I think the main problem for OpenBSD is that the package manager provide the latest stable, but not the nightly rust. Thus, you'll have to compile the compiler yourself if you want nightly as the rust project do not distribute rust for OpenBSD.

Yes this is correct and the packaging system also only will formally support crates from crates.io not from git directly. Perhaps that happens in the future, but not currently. There are workarounds but nothing that invokes pride in ones work.

@est31

@est31 no more than updating a nightly, no? Note that the build infrastructure of firefox just do that.

But I agree that it is a workaround, and quite dirty one.

Enable compilation with stable Rust.

Navigation Menu

Repository navigation

Compile with stable Rust #19

95 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Compile with stable Rust #19

Description

Activity

steveklabnik commented on Dec 23, 2016

rrichardson commented on Dec 23, 2016

steveklabnik commented on Dec 23, 2016

rrichardson commented on Dec 23, 2016

mgattozzi commented on Dec 23, 2016

SergioBenitez commented on Dec 23, 2016

beefsack commented on Dec 24, 2016

mgattozzi commented on Dec 24, 2016

tbu- commented on Apr 6, 2017

FlogramMatt commented on May 1, 2017

FlogramMatt commented on Oct 21, 2017

messense commented on Mar 23, 2018

95 remaining items

PAStheLoD commented on Dec 1, 2020

jcbritobr commented on Dec 1, 2020

schrieveslaach commented on Dec 1, 2020

viniciusd commented on Dec 1, 2020

jcbritobr commented on Dec 1, 2020

blackghost1987 commented on Dec 1, 2020

montdidier commented on Feb 26, 2021

PAStheLoD commented on Mar 2, 2021

TeXitoi commented on Mar 2, 2021

TeXitoi commented on Mar 2, 2021

est31 commented on Mar 2, 2021

montdidier commented on Mar 3, 2021

montdidier commented on Mar 3, 2021

TeXitoi commented on Mar 3, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions