Am I missing something?
I'm tired, but I feel like the compiler is wrong here.
#[macro_use]
extern crate serde_derive;
extern crate serde;
extern crate bincode;
fn foo<T>(t: &T) where T: serde::ser::Serialize {
let encoded: Vec<u8> = bincode::serialize(t, bincode::Infinite).unwrap();
}
On nightly, errors with:
error[E0277]: the trait bound `T: serde::ser::Serialize` is not satisfied
--> /foo/src/lib.rs:7:28
|
7 | let encoded: Vec<u8> = bincode::serialize(t, bincode::Infinite).unwrap();
| ^^^^^^^^^^^^^^^^^^ the trait `serde::ser::Serialize` is not implemented for `T`
|
= help: consider adding a `where T: serde::ser::Serialize` bound
= note: required by `bincode::serialize`
My cargo dependencies:
serde = "*"
serde_derive = "*"
bincode = "*"
Posted Apr 24, 2017, 6:20 PM UTC · edited
316
Check your cargo.lock to ensure that you don't have two versions of serde being used.
Oh shit nice one. I did.
Bincode depends on serde 0.9.15. My library utilizing bincode is used in my other program that's also using serde (via
serde = "*"). Except the most recent version of serde is 1.0.1.So there's the clash.
(
cargo tree, viacargo install cargo-tree, is very useful for debugging this sort of stuff)Maybe just try to run
cargo updateright off the bat? (Mentioned just in case OP isn't aware of that command)I did this locally and that's what showed up in Cargo.lock. This is most likely the problem you're having. I set it to the version bin code uses for serde to v0.9.15 and it worked. You might want to put an issue to have bincode update to version 1.0 of serde
It seems like bincode master already uses 1.0 of serde. Hm.
Probably just not pushed to crates.io yet
I think it'd be helpful to improve compiler to detect these cases and print appropriate message. Is there an issue for that already?
It already does, just not all cases. Not sure why it didn't here.
Good to know.
I've run into this problem quite a few times (especially with game projects, since Piston and Amethyst have very, very many dependencies that are only occasionally re-exported), and I've never seen a helpful error message for it. In which circumstances is it detected?
I don't recall; I think when paths match in a type error, but it's not a perfect analysis.