Closed
Description
As discussed in https://github.com/rust-lang/rust/pull/45072, we have a newer approach to handling type annotations on closure arguments that should allow us to give clearer errors in many cases. Currently, if the user annotations would yield a unification error, we wind up falling back to some more general code. So for example in the ui/anonymous-higher-ranked-lifetime.rs
test, for code like:
fn g2<F>(_: F) where F: Fn(&(), fn(&())) {}
fn main() {
g2(|_: (), _: ()| {});
}
we generate
[00:39:53] error[E0631]: type mismatch in closure arguments
[00:39:53] --> $DIR/anonymous-higher-ranked-lifetime.rs:18:5
[00:39:53] |
[00:39:53] 18 | g2(|_: (), _: ()| {});
[00:39:53] | ^^ ----------------- found signature of `fn((), ()) -> _`
[00:39:53] | |
[00:39:53] | expected signature of `for<'r> fn(&'r (), for<'s> fn(&'s ())) -> _`
[00:39:53] |
[00:39:53] = note: required by `g2`
but we could now generate something specific to one of the parameter types, rather like:
[00:39:53] error[E0631]: type mismatch in closure argument
[00:39:53] --> $DIR/anonymous-higher-ranked-lifetime.rs:18:5
[00:39:53] |
[00:39:53] 18 | g2(|_: (), _: ()| {});
[00:39:53] | ^^ argument needs type `&()`
[00:39:53] |
[00:39:53] = note: expected type `&()`
[00:39:53] found type `()`
To do this, we would want to search around for the FIXME(#45727)
-- this identifies the newer code, which is currently running in a transaction and falling back to the older strategy in the event of error.