Open dnsco opened 5 years ago
Interesting. Do you have a repro?
Here's a trivial repro case:
#[macro_use]
extern crate tower_web;
extern crate tokio;
use tower_web::ServiceBuilder;
pub fn main() {
let addr = "127.0.0.1:8080".parse().expect("Invalid address");
println!("Listening on http://{}", addr);
ServiceBuilder::new()
.resource(Routes {})
.run(&addr)
.unwrap();
}
#[derive(Clone, Debug, Response)]
pub struct Routes {}
impl_web! {
impl Routes {
#[get("/")]
fn hello_world( & self ) -> Result < String, () > {
Ok(format!("HEY BUCKO!"))
}
}
}
this works without the derive Response.
I hit this when trying to use the handlebars templating, which necessitated deriving a response (the content type and template macros did not raise any errors).
The derive response was originally on an associated struct that the methods were returning, but I removed that from the code because it didn't seem relevant.
this is using:
[package]
name = "wat"
version = "0.1.0"
edition = "2018"
[dependencies]
tokio = "^0.1.15"
tower-web = "^0.3.4"
Same error here with https://paste.ee/p/HEvPJ Also I'm hitting "unimplemented!" errors and "web is a reserved keyboard" !?
I just retried and I get the same error with your handlebars example Using
[dependencies]
tower-web="0.3"
tokio="0.1"
serde = "1.0.70"
serde_derive = "1.0.70"
serde_json = "1.0.24"
serde_plain = "0.3.0"
serde_urlencoded = "0.5.1"
error[E0433]: failed to resolve: use of undeclared type or module `http`
--> src/main.rs:23:17
|
23 | #[derive(Debug, Response)]
| ^^^^^^^^ use of undeclared type or module `http`
error: aborting due to previous error
@denniscollective @emschwartz I've fixed the compile error when adding the http crate.
So to get a) Extract
and b) Response
to run you need the following cargo.toml
[dependencies]
tower-web="0.3"
tokio="0.1"
serde = "1.0.70"
serde_derive = "1.0.70"
serde_json = "1.0.24"
serde_plain = "0.3.0"
serde_urlencoded = "0.5.1"
http = "0.1.7"
Edit: I still had to switch over to actix as I got unimplemented! and handlebars-not-found runtime exceptions with the examples.
Thanks! I will investigate now.
Ah, I bet edition 2018 has something to do with it...
I opened #185 to fix the http
issue.
Fixing the _serde
issue will require an upstream change: https://github.com/serde-rs/serde/issues/1487
As a work around for now, you may include the following dependencies in your Cargo.toml
:
serde = "1"
http = "0.1"
Additionally, Rust 2018 macro imports are not supported yet. Supporting this will require a breaking change release to tower-web.
For now, using [macro_use] extern crate tower_web;
works.
I'm pretty used to [macro_use] extern crate ..
, it's kinda the default everywhere.
Is it still normal that I get "not yet implemented" panics when trying to use extract & response with structs ?
@0xpr03 no... could you provide a backtrace?
I pushed a new version of tower-web-macros
that fixes the http
issue.
Ok so the last update fixed my "not yet implemented" panics. Not sure what exactly caused this.
Hm, for some reason I'm hitting that bug again. I can't seem to reproduce it with the same cargo.toml and same request structure in my clean test-setup.
thread 'tokio-runtime-worker-4' panicked at 'not yet implemented', /home/aron/.cargo/registry/src/github.com-1ecc6299db9ec823/tower-web-0.3.5/src/extract/serde.rs:54:17
note: Run with `RUST_BACKTRACE=1` for a backtrace.
#[post("/instance/stop")]
#[content_type("application/json")]
fn instance_stop(&self, data: InstanceStopReq) -> Fallible<DefaultResponse> {
debug!("stop request: {:?}",data);
Ok(DefaultResponse{success: true,msg: None})
}
#[derive(Debug, Clone, Extract)]
pub struct InstanceStopReq {
pub a: i32,
}
Edit: Giving up after 2h of investigation. Will look at this again tomorrow.
Ok I've found the error: Don't name "body" anything else than "body":
#[post("/instance/stop")]
#[content_type("application/json")]
fn instance_stop(&self, body: InstanceStopReq) -> Fallible<DefaultResponse> {
debug!("stop request: {:?}",body);
Ok(DefaultResponse{success: true,msg: None})
}
This works, exactly due to body instead of data or anything else. Otherwise tower-web will throw around "not yet implemented" errors.. This took me way more time than it should. Yes the docs state you should call it "body", still I didn't find that bug until looking into it for some hours.
Sorry for hijacking the issue. Unrelated to the dependency problem.
That isn't a good error for sure.
body
is the way tower-web knows to extract the data from the HTTP body. Eventually, i would add an attribute to allow renaming, but for now it is only via var names.
In hindsight it makes totally sense, but the error message and the fact that you normally can rename anything led me to trying around, believing I still have a serde dependency problem.
I'm unable to derive a response, yielding the error in the title.
I'm on stable (1.32.0), with edition 2018 enabled.
Sorry if this is not appropriate issue– but I'm a beginner and have spent a few hours trying to get around this issue.
Thanks for your work!