I have been away from Rust for a couple of years, and have got "rusty", and am at a bit of loss to understand what has happened here.
I am running nightly. On my pstd crate when I run
cargo test -F stdtests
I get a load of errors, all of this form
error[E0283]: type annotations needed
--> src/collections/btree_map/stdtests.rs:460:5
|
460 | assert_eq!(range_keys(&map, (Included(size + 1), Unbounded)), vec![]);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type
|
= note: multiple `impl`s satisfying `i32: PartialEq<_>` found in the following crates: `core`, `serde_json`:
- impl PartialEq for i32;
- impl PartialEq<serde_json::Value> for i32;
= note: required for `Vec<i32>` to implement `PartialEq<Vec<_>>`
= note: this error originates in the macro `assert_eq` (in Nightly builds, run with -Z macro-backtrace for more info)
Some errors have detailed explanations: E0282, E0283, E0432.
For more information about an error, try `rustc --explain E0282`.
error: could not compile `pstd` (lib test) due to 27 previous errors
I am not sure, but I think it used to compile two years ago, so I think something changed.
It seems it is seeing PartialEq from the serde crate, but I don't know why.
So I am feeling stupid. Help!
It seems like the problem is that the type of vec![] cannot be inferred; it could be an empty vector of type Vec<T> where i32: PartialEq<T>, but there's not a unique such T. TBH I would think that should fail due to orphan rule -related stuff (even if no other visibly imported type had that ambiguity), since it would make introducing a new type Foo that impls PartialEq<Foo> for i32 a breaking change. I wouldn't know why it was allowed and why it broke without looking into more details.
The fix, I think, is to replace vec![] with Vec::<i32>::new().
I don't really want to put in 27 type annotations, instead I think I need to figure out how to stop impl PartialEq<serde_json::Value> for i32; being "active". I don't quite understand how it is, although I remember (vaguely) that stuff like this can be pulled in automatically (I am not explaining this well).
Maybe I did the wildcard use thinking it wouldn't cause a problem and never got round to testing it. I think that is probably it.Or perhaps I added the serde stuff but never got round to checking that stdtests still worked.
Yes, multiple wildcard uses that involve traits is an unfortunate foot-gun of the trait resolution system. Ideally the diagnostic should be clearer about what's going on here so that it tells you that skipping some import will resolve the error. Updated the ticket linked above with that request.