Build error on nightly-2017-12-21

[ghost]

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;

[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?

[ghost]

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.

[HeroicKatora]

Given the previous discussion here and a seemingly hectic environment from the scale of this project, this comments might not be appreciated.

But from a security standpoint, I do understand his firm stance on supporting only a single version. There has been at least one fix of a CVE issue as far as I can see¹, possibly more which I don't spot on first glance. With limited time, the author might be very uncomfortable with encouraging support for potentially insecure version of a crypto library.

This, of course, isn't very helpful to the progress of this issue. But given that it is open source afterall, and forking can be done pretty much effortlessly, I think the outright spite coming here is disrespectful and very much out of place.

@SirRade @SergioBenitez Thanks for your work and keeping it professional and constructive.

¹ Seems like this had not affected the library in any way, but it potentially could have. I made this point simply to show that non-linear versioning with backports can have security implications. Several linux distros are able to keep this up only as a result of dedicated people specifically maintaining high-quality backports.

[briansmith]

at least one fix of a CVE issue

I guess you are referring to the code we imported from BoringSSL regarding CVE-2017-3736. CVE-2017-3736 didn't affect ring (nor did it affect BoringSSL) and those changes were just imported so they didn't get lost. In the future we might enable that optimization but only after more verification has been done; the verification process is actually what found that vulnerability in the first place.

In any case, I wrote down the versioning story for ring at https://github.com/briansmith/ring#versioning--stability. I'm sure I'd already told the policy to one or more of the Rocket maintainers before so I don't think it's a surprise. It's actually the same policy that BoringSSL upstream has, more-or-less. It's OK if people don't like the policy but it's really not productive to keep debating it over and over. Basically dealing with the version number bumps is the price of ring. I hope that we've all made ring valuable enough where people think that price is fair; if we haven't, then I'd still rather increase ring's value than decrease its price. In any case, everybody using the same, newest, version is valuable to everybody on its own; it's sort of a herd immunity.

[bbigras]

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

classy

[ghost]

As a result the origin error from cookie crate which use lower ring version, should bump to newest ring version

[SergioBenitez]

I'm sure I'd already told the policy to one or more of the Rocket maintainers before so I don't think it's a surprise.

The policy isn't a surprise. What is truly surprising is that you are unwilling to make an exception to your policy when it is likely warranted. In this particular instance, a mistake in ring breaks other people's code. Dozens of crates, including Rocket, are unable to build on nightly releases. Even when I submitted a PR making it absolutely trivial for you to resolve the issue, you maintained that you won't break your policy. It's very bothersome that you'd rather have an entire ecosystem of crates break than resolve the issue at the expense of a policy exception.

Basically dealing with the version number bumps is the price of ring. I hope that we've all made ring valuable enough where people think that price is fair; if we haven't, then I'd still rather increase ring's value than decrease its price. In any case, everybody using the same, newest, version is valuable to everybody on its own; it's sort of a herd immunity.

The issue isn't that crates want to lag behind using older versions of ring. I'd bargain that most crate authors want to be running the latest version of ring, and that includes me. The issue is that you've made upgrading ring difficult and sometimes outright impossible by rejecting briansmith/ring#575. This is counterproductive to your efforts; it forces crates to depend on the oldest version of ring in use by any of their dependencies. This means that crates are more likely to be using older versions of ring for a longer amount of time. This isn't herd immunity. This is a virus.

It's OK if people don't like the policy but it's really not productive to keep debating it over and over.

Discussing a recurring issue with a multitude of implications feels like a productive use of conversation to me. Open discourse is at the core of open source software. Stifling it is antithetical.

[janhohenheim]

@HeroicKatora very good input, completely agree.

@briansmith I definitely see your concern. I hope you see that we are not attacking you or your policy in general. I think we can all agree that keeping a consistent versioning policy is a very good thing for all participants in an Open Source environment and that we are all thankful for your work in both this regard and the ring crate itself.
The only thing we ask is a little exception given both the inherently exceptional nature of the issue at hand (as @theduke mentioned) and the extend of other crates that are directly affected. As far as I see it, and please correct me if I'm wrong, merging the PR wouldn't really bring any problems to anyone, would it?

[briansmith]

According to https://crates.io/crates/rocket/reverse_dependencies there are less than 30 crates on crates.io that depend on Rocket. It turns out I did an experiment where I sent PRs to many ring-based projects to upgrade their dependencies. One tweet about it is at https://twitter.com/BRIAN_____/status/862017683054747648. In the end I think I updated close to 40 crates to the newest version of ring and/or Rustls and/or tokio-rustls. Most of the PRs were merged within 24 hours and almost all of them were merged within a week. This is just one person spending ~3 hours total effort. Based on that experiment I feel confident that it is reasonable to simply ask people to use the latest version of ring and update all the transitive dependencies. So that's what I recommend you do.

Meanwhile I'll use the time I save from exiting this discussion to play with my small daughter and add new improvements to ring, webpki, and Rustls. Cheers!

[briansmith]

[...] upgrading ring [is] difficult [because of] briansmith/ring#575

briansmith/ring#575 is a duplicate of briansmith/ring#535. See my response at briansmith/ring#535 (comment).

[Michael-F-Bryan]

According to https://crates.io/crates/rocket/reverse_dependencies there are less than 30 crates on crates.io that depend on Rocket.

Most projects which use rocket are going to be private executables and not published on crates.io, so a more accurate figure for the number of people affected by this issue would be to search GitHub, showing roughly 2900 Rocket projects, of which I'd expect about 5-10% to be active (150-300).

---

For anyone else coming here because they're having the same issue, until all dependencies update to ring v0.13 and publish a new major version a workaround is to either use the last nightly which worked:

$ rustup override set nightly-2017-12-21

Alternatively, with a couple tweaks from @SergioBenitez we'll be able to use the [replace] section in Cargo.toml to use a patched version of ring.

  # Cargo.toml

  [dependencies]
  rocket = "0.3.5"
  rocket_codegen = "0.3.5"

+ [replace]
+ "ring:0.11.0" = { git = "https://github.com/SergioBenitez/ring", branch = "v0.11" }
+ "ring:0.12.0" = { git = "https://github.com/SergioBenitez/ring", branch = "v0.12" }

It's an ugly hack, but hopefully using the [replace] section should be enough to let people keep working while we're waiting for the necessary dependencies to update.

Instructions for @SergioBenitez

For the [replace] thing to work, you'll just need to go to both of those PR branches and change the version number in Cargo.toml back from 0.11.1 to 0.11.0 (and same for 0.12). This is because the docs say

Note that when a crate is overridden the copy it's overridden with must have both the same name and version, but it can come from a different source (e.g. git or a local path).

[cgm616]

In order to use @SergioBenitez's tweaks without changing the version number, we should be able to use the [patch] section of Cargo.toml like this (provided we use the git version of rocket):

[dependencies]
rocket = { git = "https://github.com/SergioBenitez/Rocket" }
rocket_codegen = { git = "https://github.com/SergioBenitez/Rocket" }
rocket_contrib = { git = "https://github.com/SergioBenitez/Rocket" }

[patch.crates-io]
ring = { git = "https://github.com/SergioBenitez/ring", branch = "v0.12" }

I've tested this on the latest nightly, and it compiles no problem.

[SergioBenitez]

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.

[rrichardson]

Thank you for working so diligently to provide a short and long term solution. And also thanks for everything else.

[messense]

I am using the patch solution, but I got this error on Ubuntu 16.04 with release build, debug build works fine.

error: failed to run custom build command

error: failed to run custom build command for `ring v0.11.1 (https://github.com/SergioBenitez/ring?branch=v0.11#ca9fe986)`
--- stderr
In file included from crypto/ec/ecp_nistz384.inl:24:0,
                 from crypto/ec/gfp_p384.c:262:
In function ‘add_precomputed_w5’:
crypto/ec/ecp_nistz.h:106:20: error: inlining failed in call to ‘booth_recode.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline void booth_recode(BN_ULONG *is_negative, unsigned *digit,
                    ^
cc1: error: called from here [-Werror=inline]
In function ‘GFp_nistz384_point_mul’:
crypto/ec/ecp_nistz.h:106:20: error: inlining failed in call to ‘booth_recode.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline void booth_recode(BN_ULONG *is_negative, unsigned *digit,
                    ^
cc1: error: called from here [-Werror=inline]
cc1: all warnings being treated as errors
thread '<unnamed>' panicked at 'execution failed', /root/.cargo/git/checkouts/ring-2c579f90624d41ee/ca9fe98/build.rs:657:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
In file included from crypto/limbs/limbs.c:21:0:
In function ‘LIMBS_less_than’:
crypto/limbs/limbs.inl:99:21: error: inlining failed in call to ‘limb_sub.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sub(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:84:21: error: inlining failed in call to ‘limb_sbb.part.1’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sbb(Limb *r, Limb a, Limb b, Carry borrow_in) {
                     ^
cc1: error: called from here [-Werror=inline]
In function ‘LIMBS_reduce_once’:
crypto/limbs/limbs.inl:99:21: error: inlining failed in call to ‘limb_sub.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sub(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:84:21: error: inlining failed in call to ‘limb_sbb.part.1’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sbb(Limb *r, Limb a, Limb b, Carry borrow_in) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:99:21: error: inlining failed in call to ‘limb_sub.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sub(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:84:21: error: inlining failed in call to ‘limb_sbb.part.1’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sbb(Limb *r, Limb a, Limb b, Carry borrow_in) {
                     ^
cc1: error: called from here [-Werror=inline]
In function ‘LIMBS_add_assign’:
crypto/limbs/limbs.inl:112:21: error: inlining failed in call to ‘limbs_add.part.4’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limbs_add(Limb r[], const Limb a[], const Limb b[],
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:69:21: error: inlining failed in call to ‘limb_add.part.2’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_add(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:54:21: error: inlining failed in call to ‘limb_adc.part.3’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_adc(Limb *r, Limb a, Limb b, Carry carry_in) {
                     ^
cc1: error: called from here [-Werror=inline]
In function ‘LIMBS_add_mod’:
crypto/limbs/limbs.inl:112:21: error: inlining failed in call to ‘limbs_add.part.4’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limbs_add(Limb r[], const Limb a[], const Limb b[],
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:69:21: error: inlining failed in call to ‘limb_add.part.2’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_add(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:54:21: error: inlining failed in call to ‘limb_adc.part.3’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_adc(Limb *r, Limb a, Limb b, Carry carry_in) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:99:21: error: inlining failed in call to ‘limb_sub.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sub(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:84:21: error: inlining failed in call to ‘limb_sbb.part.1’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sbb(Limb *r, Limb a, Limb b, Carry borrow_in) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:99:21: error: inlining failed in call to ‘limb_sub.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sub(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:84:21: error: inlining failed in call to ‘limb_sbb.part.1’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sbb(Limb *r, Limb a, Limb b, Carry borrow_in) {
                     ^
cc1: error: called from here [-Werror=inline]
In function ‘LIMBS_sub_assign’:
crypto/limbs/limbs.inl:123:21: error: inlining failed in call to ‘limbs_sub.part.5’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limbs_sub(Limb r[], const Limb a[], const Limb b[],
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:99:21: error: inlining failed in call to ‘limb_sub.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sub(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:84:21: error: inlining failed in call to ‘limb_sbb.part.1’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sbb(Limb *r, Limb a, Limb b, Carry borrow_in) {
                     ^
cc1: error: called from here [-Werror=inline]
In function ‘LIMBS_sub_mod’:
crypto/limbs/limbs.inl:123:21: error: inlining failed in call to ‘limbs_sub.part.5’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limbs_sub(Limb r[], const Limb a[], const Limb b[],
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:99:21: error: inlining failed in call to ‘limb_sub.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sub(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:84:21: error: inlining failed in call to ‘limb_sbb.part.1’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sbb(Limb *r, Limb a, Limb b, Carry borrow_in) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:69:21: error: inlining failed in call to ‘limb_add.part.2’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_add(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:54:21: error: inlining failed in call to ‘limb_adc.part.3’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_adc(Limb *r, Limb a, Limb b, Carry carry_in) {
                     ^
cc1: error: called from here [-Werror=inline]
In function ‘LIMBS_sub_mod_ex’:
crypto/limbs/limbs.inl:123:21: error: inlining failed in call to ‘limbs_sub.part.5’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limbs_sub(Limb r[], const Limb a[], const Limb b[],
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:99:21: error: inlining failed in call to ‘limb_sub.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sub(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:84:21: error: inlining failed in call to ‘limb_sbb.part.1’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sbb(Limb *r, Limb a, Limb b, Carry borrow_in) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:84:21: error: inlining failed in call to ‘limb_sbb.part.1’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sbb(Limb *r, Limb a, Limb b, Carry borrow_in) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:69:21: error: inlining failed in call to ‘limb_add.part.2’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_add(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:54:21: error: inlining failed in call to ‘limb_adc.part.3’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_adc(Limb *r, Limb a, Limb b, Carry carry_in) {
                     ^
cc1: error: called from here [-Werror=inline]
In function ‘LIMBS_shl_mod’:
crypto/limbs/limbs.inl:99:21: error: inlining failed in call to ‘limb_sub.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sub(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:84:21: error: inlining failed in call to ‘limb_sbb.part.1’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sbb(Limb *r, Limb a, Limb b, Carry borrow_in) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:99:21: error: inlining failed in call to ‘limb_sub.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sub(Limb *r, Limb a, Limb b) {
                     ^
cc1: error: called from here [-Werror=inline]
crypto/limbs/limbs.inl:84:21: error: inlining failed in call to ‘limb_sbb.part.1’: call is unlikely and code size would grow [-Werror=inline]
 static inline Carry limb_sbb(Limb *r, Limb a, Limb b, Carry borrow_in) {
                     ^
cc1: error: called from here [-Werror=inline]
cc1: all warnings being treated as errors
thread '<unnamed>' panicked at 'execution failed', /root/.cargo/git/checkouts/ring-2c579f90624d41ee/ca9fe98/build.rs:657:9
In file included from crypto/ec/ecp_nistz256.c:32:0:
In function ‘GFp_nistz256_point_mul’:
crypto/ec/ecp_nistz.h:106:20: error: inlining failed in call to ‘booth_recode.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline void booth_recode(BN_ULONG *is_negative, unsigned *digit,
                    ^
cc1: error: called from here [-Werror=inline]
crypto/ec/ecp_nistz.h:106:20: error: inlining failed in call to ‘booth_recode.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline void booth_recode(BN_ULONG *is_negative, unsigned *digit,
                    ^
cc1: error: called from here [-Werror=inline]
crypto/ec/ecp_nistz.h:106:20: error: inlining failed in call to ‘booth_recode.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline void booth_recode(BN_ULONG *is_negative, unsigned *digit,
                    ^
cc1: error: called from here [-Werror=inline]
In function ‘GFp_nistz256_point_mul_base’:
crypto/ec/ecp_nistz.h:106:20: error: inlining failed in call to ‘booth_recode.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline void booth_recode(BN_ULONG *is_negative, unsigned *digit,
                    ^
cc1: error: called from here [-Werror=inline]
crypto/ec/ecp_nistz.h:106:20: error: inlining failed in call to ‘booth_recode.part.0’: call is unlikely and code size would grow [-Werror=inline]
 static inline void booth_recode(BN_ULONG *is_negative, unsigned *digit,
                    ^
cc1: error: called from here [-Werror=inline]
cc1: all warnings being treated as errors
thread '<unnamed>' panicked at 'execution failed', /root/.cargo/git/checkouts/ring-2c579f90624d41ee/ca9fe98/build.rs:657:9

warning: build failed, waiting for other jobs to finish...

I think this is related to briansmith/ring#523

[SergioBenitez]

@messense I pushed a commit to my ring fork that should resolve that issue. Try cargo update then rebuilding.

[tensor-programming]

Any idea when the official release will be for the workaround mentioned above in regarding briansmith/ring#575 now that stable 01-04-18 is out? The current git workaround is really messy on windows MSVC because it has to build ring from the git; the library uses YASM and perl to build through git but comes with precompiled libraries through cargo naively.

No pressure of course, just curious because I would like to use rocket in a tutorial series of mine.

[SergioBenitez]

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

[tensor-programming]

Thank you @SergioBenitez for responding so quickly and thank you for your efforts.

[kollapsderwellenfunktion]

i just want to thank Sergio for his efforts - it saved my day.

[fschutt]

It would be nice to have these instructions in the README. Rocket has been broken for three weeks now (and it is forseeable that the PR on ring won't be merge anytime soon (i.e. it's going to take a few days / weeks to resolve errors)). This is not good. It's not nice to have to dive into issues in order to figure out how to build the library.

My build error:

   Compiling ring v0.11.0
error: ~/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.11.0/src/arithmetic/arithmetic.rs:15: 
file not found for module `montgomery`
help: ~/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.11.0/src/arithmetic/arithmetic.rs:15: 
name the file either arithmetic/montgomery.rs or arithmetic/montgomery/mod.rs inside the directory "~/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.11.0/src/arithmetic"
error: Could not compile `ring`.

For anyone coming from Google: You can fix it by putting this in the Cargo.toml and deleting the Cargo.lock file:

[dependencies]
rocket = { git = "https://github.com/SergioBenitez/Rocket", branch = "v0.3" }
rocket_codegen = { git = "https://github.com/SergioBenitez/Rocket", branch = "v0.3" }
rocket_contrib = { git = "https://github.com/SergioBenitez/Rocket", branch = "v0.3" }

[patch.crates-io]
ring = { git = "https://github.com/SergioBenitez/ring", branch = "v0.11" }

This was already said before, I just wanted to comment again, so people can more easily copy-paste it in their Cargo.toml files. Should Rocket be broken longer, please put this in the README. Thank you for your effort.

[Boscop]

I agree, it should be the first thing in the Readme, it took me hours to figure out how to fix my build a few days ago when I updated my nightly, because I had to update rocket to the latest fix. (I even had to install perl and yasm on Windows to build ring).

FWIW, this is what I settled with, (with nightly 01-08) and it works:

rocket = { git = "https://github.com/SergioBenitez/Rocket", version = "0.4.0-dev" }
rocket_codegen = { git = "https://github.com/SergioBenitez/Rocket", version = "0.4.0-dev" }
rocket_contrib = { git = "https://github.com/SergioBenitez/Rocket", version = "0.4.0-dev" }
cookie = { git = "https://github.com/alexcrichton/cookie-rs", rev = "a15b37a", features = ["percent-encode", "secure"] }

Because I need that cookie SameSite fix (being able to set SameSite to None).

And in my workspace root Cargo.toml:

[patch.crates-io]
ring = { git = "https://github.com/SergioBenitez/ring", branch = "v0.12" }

Is it a good idea to use version = "0.4.0-dev" for rocket but rev = "a15b37a" for cookie? How to do it better? (Cookie introduced that SameSite fix in that commit, which I need.)

But now, how can I [patch] the rocket dependency of the rocket_cors crate so that it uses the same rocket version?

[ghost]

@Boscop
You can clone rocket_cors and edit rocket_cors's Cargo.toml to update rocket to rocket = { git = "https://github.com/SergioBenitez/Rocket", version = "0.4.0-dev" }, and in your project Cargo.toml alter rocket_cors to rocket_cors = { path = "./rocket_cors" } the path is of your rocket_cors cloned.
And im tested it's build and running OK!~

[Boscop]

Yeah, that's what I did.
I was just wondering if there is a way to override rocket_cors's rocket dependency without having to use a fork.

[jplatte]

It should be possible to override any indirect dependency with [patch]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#overriding-dependencies

[awalcutt]

Adding a crates.io [patch] as @jplatte suggested should work. I had to do the same thing in my project to fix some issues with Maud (trait impls broke when I had two versions of Rocket)

https://github.com/awalcutt/WeddingWebsite/blob/master/Cargo.toml#L14

[SergioBenitez]

Today's (2018-01-12) nightly release includes a commit (rust-lang/rust#47298) that reverts the change that broke 'ring', un-breaking 'ring', and thus un-breaking Rocket! As a result, the [patch] workaround is no longer required. With the release of Rocket v0.3.6, Rocket is back on the latest nightly! Updating your Rust installation and Rocket version resolves this issue.

Thank you all, again, for your support!