Open
Description
struct Foo<T, F: Fn(&T, &T) -> T> {
value: T,
func: F
}
fn main() {
let lambda = |&x, &y| x + y;
let foo = Foo {
value: 5 as i32,
func: lambda
};
}
Compiling playground v0.0.1 (/playground)
error[E0308]: mismatched types
--> src/main.rs:8:15
|
8 | let foo = Foo {
| ^^^ one type is more general than the other
|
= note: expected type `std::ops::FnOnce<(&i32, &i32)>`
found type `std::ops::FnOnce<(&i32, &i32)>`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
error: Could not compile `playground`.
To learn more, run the command again with --verbose.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
estebank commentedon Jan 24, 2019
This is a diagnostics regression given the current stable output (even though it wasn't that good to begin with):
but needs consideration on wether the code as written should be accepted instead. Why are we evaluating to
FnOnce
in the first place? Note that changingF
toFnMut
doesn't change the types reported.CC @rust-lang/lang
ExpHP commentedon Jan 24, 2019
Is it not just showing
FnOnce
because the associated type is defined on FnOnce? This isn't related to the fact that it does not compile.ExpHP commentedon Jan 24, 2019
The workaround is to annotate the closure parameter types so that they get assigned higher-ranked regions or whatever you call them.
This is a well-known problem that has hit many a rustacean. But I thought the error messages used to be more descriptive, saying mething about "concrete" versus "bound" lifetimes. Even if it was terribly confusing language, it was at least something the user could Google.
lqd commentedon Jan 27, 2019
This issue is very similar to #57362 on which I have been working (same RegionResolutionError: a SubSupConflict with two placeholder regions and Subtype region origins — but in this case the expected/found values are PolyTraitRefs instead of TraitRefs, bypassing the nice_region_errors into this "mismatched types" fallback which doesn't show the self tys) and I hope to look into this one next.
kadiwa4 commentedon Feb 26, 2023
Current output (rustc 2023-02-25):
very long, but the problem is made clear
estebank commentedon Mar 4, 2023
Really happy to see progress on this front! The last two errors should not be emitted (as they are redundant), but at the very least it should be only one, so I'll leave the ticket open, but I'm ok with the current output as is.
RodBurman commentedon Dec 19, 2024
I think the errors emitted have got worse again, as compiling with:
Produces: