rust-lang-deprecated / failure

Error management

Home Page:https://rust-lang-nursery.github.io/failure/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

failure_derive won't build with quote 1.0.3

turboladen opened this issue · comments

My CI builds just started failing with the following error:

error[E0433]: failed to resolve: could not find `__rt` in `quote`
   --> /Users/sloveless/.cargo/registry/src/github.com-1ecc6299db9ec823/failure_derive-0.1.6/src/lib.rs:107:70
    |
107 | fn display_body(s: &synstructure::Structure) -> Result<Option<quote::__rt::TokenStream>, Error> {
    |                                                                      ^^^^ could not find `__rt` in `quote`

Looks like the quote crate renamed __rt to __private in its 1.0.3 release that just came out: dtolnay/quote@4154389

Same issue in my crates, with the same version of failure_derive too (github.com-1ecc6299db9ec823/failure_derive-0.1.6).

same issue here

same issue here

I asked in the Rust Discord channel on how to pin a version for all dependencies until the fix is deployed.

In Your Cargo.toml
quote = "=1.0.2"

Do you think we could get this shipped as a point release to crates.io soonish as we're going to get widespread ecosystem breakages without this PR @mitsuhiko ?

The idea to use quote = "=1.0.2" is not working for us as this package is not our dependency. Right now doing cargo install wasm-pack fails, which is a 3rd-party binary for us. Is there any way to change in Rust the dependency version of a binary that we install with cargo install ?

commented

@wdanilo cargo install wasm-pack --locked should do it.

@est31 Thank you. By the way, do you know if there is any way to add quote = "=1.0.2" only to cargo.lock, as this is not our dependency and I dont want do add artificial deps to cargo.toml?

Yeah, I’ll merge the associated PR and release it to crates.io when I’m in the office within an hour.

@est31 Actually I realized this solution does not work. The problem is that cargo install wasm-pack --locked does take into consideration the Cargo.lock file, but it contains locks for our packages, not 3rd party binaries, so still the same error appears.

Can you just add quote=“=1.0.2” in the dependencies as a stopgap?

(Or maybe quote=“<=1.0.2” might be a bit kinder)

@gilescope I tried it. If you will have a free minute, I would be thankful if you could take a look here: enso-org/ide#234 (commit e7afd7e). It seems that the version was not picked up as it was still isntlaling 1.0.3

I've opened a PR to release a fix for this issue: #345.

New version of failure crate is just being published so hang on 30 mins and your problems will disappear

Sent with GitHawk

failure v0.1.7 and failure_derive v0.1.7 have just been published.

commented

Works thank you