Build error on nightly-2017-12-21

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

[SergioBenitez]

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.

[SergioBenitez]

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.

[janhohenheim]

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?

Now i just self cloned jsonwebtoken (it uses ring="0.12.0") crate cause of ring's version.

[theduke]

@SergioBenitez thanks for giving lengthy explanations and reasoning both here and in the various ring issues/PRs. Without them, I'd have had no idea what's going on.

This is admittedly a combination of bad factors (a bug in rustc, being forced to nightly due to rocket, strong opinions of a maintainer...).

I've already had to do regular dependency juggling with various projects due to ring though , and @briansmith s stances, while I'm sure they have a merit, make stable software development hard.

Even if I didn't need nightly... I want my one year old projects to build on a new stable and I also don't want to constantly be constrained in dependency version updates due to one crate tying down everyone else..

Personally, I'll try to avoid ring dependencies in the future.