Closed
Description
I just encountered this error: (newlines added to hightlight the sameness of the pretty-printer result)
error: type mismatch:
the type `fn(&mut iron::request::Request<'_>) -> core::result::Result<iron::response::Response, iron::error::IronError> {frontpage}` implements the trait
`for<'r,'r> core::ops::Fn<(&'r mut iron::request::Request<'r>,)>`, but the trait
`for<'r,'r> core::ops::Fn<(&'r mut iron::request::Request<'r>,)>` is required (expected struct
`iron::request::Request`, found a different struct
`iron::request::Request`) [E0281]
This happened to me, because I had my own debugging version of Iron linked in my Cargo.toml. However, I also had the vanilla straight-from-cargo version of Iron extension, Router, linked. Thus, my own code referenced different "iron" crate than the Router code. This made the error report confusing: it looks like the type is the exactly same, although it's from different crate.
I think there's a very simple fix: just check if the traits pretty-prints are exactly the same, and if they are, provide additional information why they are different: i.e. print the paths of the crates they are from.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
ghost commentedon Mar 10, 2015
A dupe of #22750 but the test case is a tad different so I'll leave this open.
[-]Confusing "type mismatch" error report: the types might differ while pretty-printer prints them the exactly the same way[/-][+]Confusing "type mismatch" error report: the types might differ while pretty-printer prints them in exactly the same way[/+]dotdash commentedon Apr 13, 2016
Comparing the pretty printed names is not necessarily enough. if you use
extern crate foo
once at the top-level and once withinmod bar
, you'll getexpected foo::Type found bar::foo::Type
, which in some way is even more confusing, but regardless of that, should also have a hint, that it's the same crate but in different versions.Mark-Simulacrum commentedon May 2, 2017
I'm going to close in favor of #22750 since that issue has more discussion and this issue doesn't have a specific test case that I can see.