Comments (118)
Thank you, everyone, sincerely. β€οΈ
from rocket.
The last remaining feature has just been merged! Finally Rocket will be able to compile with stable Rust (1.45).
from rocket.
A stabilization PR for the final nightly-only feature Rocket makes use of is under review! Looks like we're within a few months of Rocket compiling on stable in earnest.
from rocket.
I'm so happy to read this!!!, I've been tracking this bug for 2 years waiting with hope. good job guys :)
from rocket.
from rocket.
Merged rust-lang/rust#69041!
Merged also rust-lang/rust#68716!
rust-lang/rust#68717 is in FCP!
from rocket.
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.
from rocket.
Stable is out now apparently, so it should compile on 1.45.x and later
from rocket.
That's one small step for a crate; one giant leap for Rustaceans
from rocket.
To the best of my knowledge that is correct. One has finished FCP, one is currently in it, and the third has yet to begin it.
If all three get merged by June 4, it will land on stable in Rust 1.45 on July 16. The async version of Rocket will then be able to compile on stable, though as far as I know there's no timeframe on a 0.5 release.
from rocket.
Status update?
from rocket.
I created a PR for Pear to remove all feature gates, though doing so appears require some mild lifetime changes in &str parameters.
As of today the beta compiles all code except for https://github.com/SergioBenitez/Pear/blob/master/codegen/src/parser.rs#L168 . https://doc.rust-lang.org/proc_macro/struct.Span.html#method.join is nightly only and in all other compilers returns None.
Open issue for Span.join is rust-lang/rust#54725
from rocket.
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?
from rocket.
Pear was the last using Nightly features AFAICT from the discussion above and the linked issues & PRs, and that was fixed today in SergioBenitez/Pear@333c9bf. The only thing that remains to do for Rocket to compile on the current beta / upcoming stable is Pear being updated.
from rocket.
Congratulations Sergio!
from rocket.
@sound2gd Rocket itself should be able to compile on stable as of today's release. Codegen is what still needs nightly.
from rocket.
As far as I know, this is currently blocked on the following dependency chain of Rust PRs, which all look well on their way:
- rust-lang/rust#68717
...which is blocked on rust-lang/rust#68716(merged)...which is blocked on rust-lang/rust#69041(merged)
from rocket.
Congrats. Will there be a 0.4.x release for this or will we have to wait for 0.5?
It will happen in 0.5. Several of the features used by 0.4 (e.g. try_trait
, specialization
) are part of public API and won't be removed.
from rocket.
That's great to see @npmccallum, thanks for the heads up. I just tried building a Rocket project with the new stable Rust 1.45.0 and the build still failed around this issue, that's what brought me here. Hopefully all that's needed at this point for this use case is a release for Pear with that merged work and then updated references to the new Pear crate version in this repo. Looking forward to that!
from rocket.
Update (May 19, 2019): proc_macro_hygiene was stabilized!
We're on 2020 now π
from rocket.
Hi, I've been holding off on making a decision about which HTTP framework to use for a project, while quietly watching progress on this one. Are there any updates about getting Rocket to run on stable Rust?
from rocket.
Note that Rocket depends on pear
, which still uses nightly features:
- https://github.com/SergioBenitez/Pear/blob/a4c5b1db60f22de88b62852d1a0da5ac992fc776/lib/src/lib.rs#L1-L3
- https://github.com/SergioBenitez/Pear/blob/a4c5b1db60f22de88b62852d1a0da5ac992fc776/codegen/src/lib.rs#L1-L3
from rocket.
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.
from rocket.
@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
from rocket.
Congrats. Will there be a 0.4.x release for this or will we have to wait for 0.5?
from rocket.
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.
from rocket.
IIRC Some of rocket
's regular dependencies in master
still use nightly features (most/all fixable by updating to a more recent version) and rocket
depends on `rocket_codegen. Therefore it would take some work to actually do so. Using Rocket without codegen is usually recommended against and loses most of Rocket's value-add, so it's not something I'm interested in investing time into in favor of working on async and other improvements for 0.5.
Presumably we could use something like cargo-expand to see the generated code, and then replace the macro invocation with the generated code?
I have usually found this to be impractical for anything other than testing, because you wouldn't want to and can't use the expansion of certain macros like format!()
. In principle it could probably be done, but would not be very nice to maintain.
from rocket.
July 16th seems to be the day for stable, and June 4th is the day for beta.
from rocket.
this is great news! is there a timeline for 0.5? i've seen the milestone which also seems to contain other features, some of which are already older issues: https://github.com/SergioBenitez/Rocket/milestone/8
would it be possible to make the 0.5 as soon as it contains everything needed to compile on stable (or, right now on beta)? this would be a huge step forward and move the library in the right direction. being able to build on a stable rust release would reduce the efforts for projects trying to use this library.
from rocket.
The current latest stable Rocket is 0.4, which still needs nightly Rust. So those updates will likely have to wait for Rocket 0.5.
from rocket.
Looks like this primarily depends on rust-lang/rust#38356
(Or syntex)
from rocket.
@rayrrr note that @Aaron1011 's links point to an outdated version of pear. In the current master version of pear (which rocket doesn't use yet as it uses the crates.io version), nightly usage has been removed from the pear_codegen crate, as well as core_intrinsics
from the pear crate. The only two remaining feature gates are for proc_macro_hygiene
, removal of which doesn't cause any errors, and specialization
, which is apparently needed for conflicting implementations of the Slice
trait.
from rocket.
Congratulations! π
from rocket.
Is there an estimated timeline for 0.5 to be released?
from rocket.
Goodbye Issue #19 Hello Stable! πΎπΎπΎ
from rocket.
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.
from rocket.
I'm really looking forward to using Rocket in production some day, I'm glad to see there's been some progress recently. :)
from rocket.
FYI, if you don't want to wait to build web services in rust, check out actix. It works on stable rust.
from rocket.
Given the recent blogpost, shouldn't the milestone on this be 0.5?
from rocket.
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.
from rocket.
Hi @SergioBenitez thanks for this project. Given that Rocket depends on Pear, would you mind describing the purpose of Pear a bit in its own README? Seems like some util traits etc. at first glance...but with a good description in the README, perhaps some other contributors can help figure out how to remove the need for nightly there too.
from rocket.
Congratulations! Don't forget to update doc
from rocket.
i can't wait for v0.5 to start experimenting. i might write a v2 app at work in rust and rocket :) now it's a monolithic-like project written in php and new features feels too much for php (e.g. no multithreading in php, slow for algorithms)
from rocket.
std::convert::Infallible
is stable in the upcoming release, that should be able to substitute for most uses of the never-type.
from rocket.
^^ I can quickly go through and issue a PR if that's something that's wanted.
from rocket.
never_type
will be stabilized 1.41.0, so you can change std::convert::Infallible
into !
from rocket.
impl Trait is scheduled to be stabilized in Rust 1.26.0 too
from rocket.
@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.
from rocket.
proc_macro
has been split into several subtasks -- which one(s) does Rocket depend on?
EDIT: Thanks!
from rocket.
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/
from rocket.
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)
from rocket.
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.
from rocket.
@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.
from rocket.
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
from rocket.
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)
from rocket.
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.
from rocket.
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!
from rocket.
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.
from rocket.
The lookup_host
feature can be replaced by the ToSocketAddrs
implementation of &str
.
from rocket.
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.
from rocket.
never_type will be stabilized in Rust 1.26.0.
from rocket.
i128 just got stabilized will ship in Rust 1.27.0.
from rocket.
macro_reexport
is now removed(not in nightly yet, incoming breaking change) and subsumed by feature(use_extern_macros
) and pub use
from rocket.
@messense PR #624 should handle those changes.
from rocket.
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.
from rocket.
Just noting, proc_macro
is in the process of being stabilized: rust-lang/rust#52081
from rocket.
@est31 Unfortunately, the stabilizing subset is extremely limited and insufficient for Rocket's needs.
from rocket.
Now there's an easier way to keep track of these things: https://forge.rust-lang.org/state-of-rust.html
from rocket.
Very happy to see this progressing!
Team Aardwolf appreciates your hard work :D
from rocket.
@incubus8 see this blog post for details on the plans: https://rocket.rs/v0.4/news/2018-12-08-version-0.4/
from rocket.
At the very least, a PR will make it obvious where it's currently used and whether Infallible
can fully replace its uses. It may not be accepted right way, especially if it would break existing code that uses the real never type.
from rocket.
@jebrosen Is there a minimum version Rocket guarantees, or is it just the current version? Asking because the initial checkout and cargo check
returns warnings for both try_from
and transpose_result
. I'll naturally remove those as well if desired.
from rocket.
@jhpratt Only the Infallible
change in one PR (at the very least separate commits) will be easier to split up later if we want to.
from rocket.
reqwest is almost stabled It's currently on 0.9.17
https://github.com/seanmonstar/reqwest
And how, if I may ask, is that relevant here?
from rocket.
hello, any update on this?
from rocket.
If we wanted to use rocket on stable and we use codegen right now, how hard do you think it would be to remove the codegen usage?
Presumably we could use something like cargo-expand to see the generated code, and then replace the macro invocation with the generated code?
from rocket.
To summarize - it's probably not useful, easy or very maintainable to use rocket without codegen. Makes sense.
Thanks for the clear explanation π
from rocket.
Is there any chance we could use this trick to remove the dependency on proc_macro_hygiene
, and get Rocket compiling on stable?
This reddit discussion suggests that it's a lot simpler than proc-macro-hack.
from rocket.
I think we could use that trick and get halfway there (we will have some diagnostics-related features to work out), but if I'm reading it right it would limit each function from calling routes!()
or uri!()
once.
from rocket.
Why doesn't Rocket just use proc-macro-hack directly? Implementation difficulty?
from rocket.
@Kampfkarren Read the comment right before yours π
from rocket.
That's in reference to the trick used by RustPython, no? Not proc-macro-hack?
from rocket.
Ah, you're right. Either way, diagnostics would definitely take a big hit.
from rocket.
The limitation I was thinking of was something else and/or outdated - I believe both proc-macro-hack
and the "extracted" version of it would be usable. When it comes down to that time, I think we could use this approach while the relevant part of proc_macro_hygiene
is unstable.
from rocket.
Also worth tracking rust-lang/rust#68716, which is necessary to get that part of proc macro hygiene stabilized.
from rocket.
The guide and examples pretty much all still use ![feature(decl_macro)]
even though the OP says it's no longer used since July 2019. Removing the ![feature(decl_macro)]
line results in failed compiles.
I feel like I'm missing something: Is the decl_macro
feature still needed or not? π€
from rocket.
@runiq decl_macro
is needed for 0.4. Future versions of rocket (0.5+) won't need it.
from rocket.
Congratulations πΎπ₯
from rocket.
Awesome news π
from rocket.
Awesome news. So when will we actually be able to build rocket with rust stable?
from rocket.
Note that those dates also only apply to the upcoming 0.5 release. 0.4 will continue to require nightly for the time being.
from rocket.
Amazing news! Congrats!
from rocket.
July 16th seems to be the day for stable, and June 4th is the day for beta.
Is that planning still accurate? Excited to see Rocket on stable :)
from rocket.
Yes, Rocket itself should be able to compile on stable in two days. I'm not sure of the dependencies are all able to be built on beta currently, though.
from rocket.
Not quite there yet...SergioBenitez/Pear#23 (comment)
from rocket.
Not quite there yet...SergioBenitez/Pear#23 (comment)
from rocket.
Big thank you and congrats!!!
I've been waiting for this eagerly over the last few days. Kept on refreshing my browser tabs. Finally!
from rocket.
Congrats. This is awesome news. Great work!
from rocket.
Congratulations! Don't forget to update doc
And crates.io front-page as well
from rocket.
The getting started page still haven't been updated yet. πππ
from rocket.
Related Issues (20)
- Redirector issue in TLS example HOT 5
- Deployment Docs - Static Files HOT 1
- FromForm Option<Result> with custom type HOT 4
- Possible error in the Json guard HOT 3
- Allow Generics in route functions HOT 1
- Caching a background image with the `Cache-Control` header HOT 2
- sslmode=required not working for rocket_db_pool with feature diesel_postgres HOT 1
- Fairing returns incorrect Content-Length for status 204 HOT 7
- No way to turn off coloured log output HOT 2
- Implement derive FromParam for enum HOT 1
- Websockets (and any other connection upgrade) does not support local testing.
- `rocket_http` doesn't bulid/test on `rust` `1.80.0` HOT 1
- Expose the `tracing` layer construction to allow you to add other e.g. tracing_subscribers HOT 2
- Implement `PartialEq` for `http::Status` with derive macro HOT 4
- SQLx, Diesel, etc RUSTSEC tracking issue. HOT 2
- Request params fetch by name HOT 5
- Routes to paths with URL-encoded chars fails to match and always results in 404 HOT 1
- A new warning on rust beta: unreachable pattern HOT 2
- How should I save the Rocket logs to a file? HOT 2
- Serving static files HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rocket.