Skip to content

Rocket Responder not working with v0.2.0? #76

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
trombonehero opened this issue Feb 24, 2017 · 4 comments
Closed

Rocket Responder not working with v0.2.0? #76

trombonehero opened this issue Feb 24, 2017 · 4 comments

Comments

@trombonehero
Copy link

I'm using Maud v0.16.1 and attempting to update Rocket from v0.1.6 to v0.2.0. The following reduced test case works fine with Rocket v0.1.6:

use rocket::response;
use rocket::response::{Responder, Response};

pub enum Foo {}

impl<'r> Responder<'r> for Foo {
    fn respond(self) -> response::Result<'r> {
        (html! {}).respond()
    }
}

With Rocket v0.2.0, however, I see:

error: no method named `respond` found for type `maud::PreEscaped<std::string::String>` in the current scope
 --> src/html/abc.rs:8:20
  |
8 |         (html! {}).respond()
  |                    ^^^^^^^
  |
  = help: items from traits can only be used if the trait is in scope; the following trait is implemented but not in scope, perhaps add a `use` for it:
  = help: candidate #1: `use rocket::response::responder::Responder;`

error: aborting due to previous error

The rocket::response::responder module is private, however, so I can't use it as suggested. I do see a respond() method at Maud's lib.rs:212 and I have features = ["rocket"] in my Cargo.toml file. Any idea why Maud's impl Responder for PreEscaped isn't being detected?

@lambda-fairy
Copy link
Owner

Can you show me the contents of your Cargo.lock? That looks like a diamond dependency issue -- if your app uses 0.2.0 but Maud is still pulling in 0.1.6, then that would explain the error.

@trombonehero
Copy link
Author

Ah, yes, that was it: there was a 0.1.6 in Cargo.lock. Deleting the lock file and rebuilding did the trick. Sorry for the noise.

@lambda-fairy
Copy link
Owner

lambda-fairy commented Feb 26, 2017

FYI, rust-lang/rust#22750 and rust-lang/cargo#2064 address different parts of this issue. I don't see much movement with either of them, though.

@TheNeikos
Copy link
Contributor

@trombonehero Deleting your Cargo.lock shouldn't be necessary, cargo update should have been enough in that case I believe (also with --precise)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants