Stuck with "trait bounds were not satisfied"/"not in scope"


I’ve tried to figure out why the serde_json build fails for --features preserve_order but I’m stuck.

$ cargo build --features preserve_order
   Compiling serde_json v0.8.0 (file:///Users/spark/prj/hjson/hjson-rust/_json/json)
src/ 383:48 error: no method named `serialize` found for type `&linked_hash_map::LinkedHashMap<std::string::String, value::Value>` in the current scope
src/             Value::Object(ref v) => v.serialize(serializer),
src/ 383:48 note: the method `serialize` exists but the following trait bounds were not satisfied: `linked_hash_map::LinkedHashMap<std::string::String, value::Value> : serde::Serialize`
src/ 467:62 error: no method named `visit_map` found for type `linked_hash_map::serde::LinkedHashMapVisitor<_, _>` in the current scope
src/                 let values = try!(MapVisitor::new().visit_map(visitor));
src/ 467:72 note: in this expansion of try! (defined in <std macros>)
src/ 467:62 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:
src/ 467:62 help: candidate #1: `use serde::de::Visitor`
error: aborting due to 2 previous errors
error: Could not compile `serde_json`.

AFAIK the requested methods are implemented in linked-hash-map and the features to include them are specified. Am I misreading the error message?


Could it be a version conflict?
I had something similar lately, where I was depending on serde 0.8 and a dependency was depending on serde 0.7.
The error messages are quite confusing in that case.

Try a cargo update or if this doesn’t work check your Cargo.lock if it contains two different versions of serde.


Thanks, that was it! linked-hash-map is still using serde 0.7. After using a version from master (that references 0.8) everything compiles without errors.


It would be great if rustc would detect such situations and give a better error message.

“A similar trait of a different version was found?” maybe?


There’s a bug filed for that here: