SolvedRocket Build error on nightly-2017-12-21

error[E0609]: no field `lifetimes` on type `&syntax::ast::Generics`
  --> /home/sackery/.cargo/registry/src/github.com-1ecc6299db9ec823/rocket_codegen-0.3.5/src/decorators/derive_form.rs:29:32
   |
29 |                 match generics.lifetimes.len() {
   |                                ^^^^^^^^^

error[E0609]: no field `lifetimes` on type `&syntax::ast::Generics`
  --> /home/sackery/.cargo/registry/src/github.com-1ecc6299db9ec823/rocket_codegen-0.3.5/src/decorators/derive_form.rs:32:49
   |
32 |                         let lifetime = generics.lifetimes[0].lifetime;
31 Answers

✔️Accepted Answer

The compiler change that caused ring's build to fail was intentional. Unfortunately, ring was explicitly ignoring a forward-compatibility warning (and later, an error) from rustc that indicated this future change. As a result, the source code was never properly updated and continued to use an unsupported feature - one that was removed in the 2017-12-21 nightly. As @cramertj puts it:

The fact that what [@briansmith] is doing in this crate ever worked was the result of a bug-- it was never a supported structure. [...] In order to make the new module system features work, this bug was fixed (following a year-long warning period, concluding with a deny-by-default phase where this warning became an error).

These issues were fixed in ring in briansmith/ring@0a198e8 and released in ring 0.13.0-alpha. Unfortunately, because only one version of ring can exist in a crate's dependency tree at once due to briansmith/ring#575, we cannot upgrade ring to 0.13.0-alpha in Rocket without a new major release, which Rocket is not ready for. The alternative is to backport the fixes to ring 0.11. I submitted a pull-request to ring that does just this (briansmith/ring#605) but it was immediately rebuffed by the author, closed, and locked. Additionally, all other discussions surrounding resolutions to these issues with ring were also locked and closed by the author: briansmith/ring#599, briansmith/ring#598, briansmith/ring#575, briansmith/ring#606.

As this point, I do not know of a path towards fixing Rocket on the latest nightlies. I will post updates on this issue as I have them.

Other Answers:

@tensor-programming The PR is in review (briansmith/ring#619). As soon as it's accepted by @briansmith and a new version of ring is published with the change, I'll release a new version of Rocket v0.3 that uses it, resolving this issue.

I've pushed changes to the v0.3 branch of Rocket that allows you to stay on a stable release of Rocket while working around this issue. To use the branch on the latest nightly, make the following changes to your Cargo.toml:

- rocket = "0.3.5"
+ rocket = { git = "https://github.com/SergioBenitez/Rocket", branch = "v0.3" }
- rocket_codegen = "0.3.5"
+ rocket_codegen = { git = "https://github.com/SergioBenitez/Rocket", branch = "v0.3" }
- rocket_contrib = "0.3.5"
+ rocket_contrib = { git = "https://github.com/SergioBenitez/Rocket", branch = "v0.3" }
 
+ [patch.crates-io]
+ ring = { git = "https://github.com/SergioBenitez/ring", branch = "v0.11" }

Now that @briansmith has reconsidered his position on briansmith/ring#575 , I'm actively working on fixing ring to definitely resolve this issue and prevent it from reoccurring in the future. However, due to a bug in the current stable Rust compiler (rust-lang/rust#44851), we won't be able to ship the fix until the next stable version of Rust is released. Thankfully this is only a few days away as version 1.23 is scheduled to be released on January 4, 2018. Until then, the workaround above is the best solution.

Thank you, everyone, for your patience and support as we've worked through this issue. It's incredible to see such a supportive community forming around Rocket.

Unfortunately the new nightly has broken ring (briansmith/ring#598) which breaks cookie which breaks rocket, so there's nothing we can do to fix rocket until a new nightly with the appropriate fix is released. I've opened up an issue (rust-lang/rust#46936) for the regression. Once that's addressed, we can push out a new release with the fix for this breakage.

Until then, you'll need to stick with the latest working nightly 2017-12-20. You should be able to install 2017-12-20 via rustup default nightly-2017-12-21.

Quote by the author:

I only support the latest released version of ring. This feature proposal is only for supporting versions of ring that aren't the latest released version, so it's out of scope., like I said before. I'm not interested in changing the policy or debating it further.

Pretty unhelpful and, in my opinion, a bit unprofessional, as the relevant work has already been done by others.
As it seems the issue cannot be fixed in ring itself, how about we fork it?

More Issues: