Confusing type error due to strange inferred type for a closure argument

[jseyfried]

This example:

pub struct Request<'a, 'b: 'a> {
    a: &'a (),
    b: &'b (),
}
pub trait Handler: Send + Sync + 'static {
    fn handle(&self, &mut Request) -> Result<(),()>;
}
impl<F> Handler for F where F: Send + Sync + 'static + Fn(&mut Request) -> Result<(),()> {
    fn handle(&self, _: &mut Request) -> Result<(),()> {
        unimplemented!()
    }
}
fn make_handler(h: &'static Handler) -> Box<Handler> {
    Box::new(move |req| h.handle(req))
}

errors with

error[E0271]: type mismatch resolving `for<'r, 'r, 'r> <[closure@<anon>:14:14: 14:38 h:_] as std::ops::FnOnce<(&'r mut Request<'r, 'r>,)>>::Output == std::result::Result<(), ()>`
  --> <anon>:14:5
   |
14 |     Box::new(move |req| h.handle(req))
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected bound lifetime parameter , found concrete lifetime
   |
   = note: concrete lifetime that was found is lifetime '_#9r
   = note: required because of the requirements on the impl of `Handler` for `[closure@<anon>:14:14: 14:38 h:_]`
   = note: required for the cast to the object type `Handler`

Annotating the closure parameter |req: &mut Response| allow the example to compile.
Interesting, annotating with |req: &&mut Response| produces a similarly-structured error, so I believe we're inferring &&mut here (maybe related to autoderef?).

[jseyfried]

cc @nikomatsakis @eddyb

[eddyb]

This is a known issue IIRC, but I don't know how to actually find the original issue.

[nikomatsakis]

Sorry, I've been putting off this tab for days trying to squeeze out some time to write a more detailed comment. But in short the problem is that we do not infer when to "generalize" the region -- in particular, we will infer a type of &'a mut Handler for some 'a, but your type demands a type of &'a mut Handler for all 'a (i.e., the difference between fn(&'a mut Handler) and for<'a> fn (&'a mut Handler). We do not (yet) infer generalizations except when the expected type provides the hint -- now, in this case, I might expect us to be able to trace things through the expected type. We would I think do so if you were returning Box<FnMut()>, but because the FnMut() requirement is "hidden" (this is a trait that happens to be implemented by closures...) we fail to deduce it. I'm pretty sure there's an open issue on this somewhere.

[gmorenz]

Just ran into this (or at least I'm pretty sure it's this, otherwise feel free to split this off into a new bug)

Smaller test case:

fn main() {
    let suitable = |_| true;
    vec![1,2,3].into_iter().find(suitable);
}

Workarounds: Inline suitable into find, or annotate suitable with a & type, i.e. let suitable = |_: &_| true.

I think all of these issues are older duplicates

• Rust has trouble seeing higher ranked lifetimes through generics #36582
• Failure to determine impls with higher-ranked lifetimes involved #32600 (which has the type annotation workaround)
• Incorrect lifetime inferred for closure #26937 (which has the inlining workaround)
• Incomprehensible error message when inference fails for closure #24680
• Generic fn cannot be converted to for<'a> Fn #22791

[Mark-Simulacrum]

More duplicates, or at least the same underlying issue:

• Incorrect lifetime error with a generic FnMut after annotating the type in a closure. #22557
• Inference failure with mutable reference to closure #34892
• proc with a reference as an argument meets lifetime errors when inferring type #14037
• HRTB bug in streaming iterator #30786 (possibly)

We should decide on a single (or two, one for the diagnostic and one for the underlying issue) canonical issue and deduplicate.

[Mark-Simulacrum]

Leaving the following issues open, since I don't think they're quite duplicates. The rest of the issues linked in the two comments above are about to be closed referencing this issue.

• Rust has trouble seeing higher ranked lifetimes through generics #36582
• Incorrect lifetime error with a generic FnMut after annotating the type in a closure. #22557
• HRTB bug in streaming iterator #30786