Complete closure expression by expected type

[flodiebold]

In a place where something implementing Fn/FnMut/FnOnce is expected, we should complete |x0, x1| $0 and move |x0, x1| $0, with the correct number of parameters of course.

This isn't completely trivial because it's not about the expected type, but about a trait bound on it. We should probably carry them over from type checking somehow; a simpler approach for now might be to only make it work if we're in a function parameter.

We might also want to make | a completion trigger character then.

CC #8629

[Veykril]

Kinda related with #3148

[flodiebold]

As noted in #9444, this isn't actually easier to do even by restricting it to function parameters :/

[flodiebold]

Here's the general problem: let's say we have

fn foo<T: Fn(u32)>(t: T) {}

fn main() {
    foo();
}

During inference, we create a type variable (let's say ?1) for the type parameter T in the foo call, and we record an obligation that ?1: Fn(u32). (So the type of the foo is foo::<?1>.) Sadly, we reach the end of the function without ever resolving the type variable to a concrete type or proving the obligation. At the end of type inference, we fallback all type variables before recording the inference result, so the foo::<?1> becomes foo::<{error}> (this is the point where we would emit a "type annotations needed" error); and we completely drop the unproven obligations. We instead need to store the unproven obligations somehow, but that also means we need to record a different type so the connection to the obligation stays intact.

Here are a few ideas for what we could do:

1. Just keep inference variables, don't do fallback. This would mean we have to deal with them everywhere in the IDE code though, which would be bad.
2. Store types without fallback separately (i.e. next to type_of_expr, also have type_of_expr_without_fallback). Then all IDE code would have to choose which type it wants, which is also not great...
3. Turn inference variables into placeholder types or bound variables. Similarly means IDE code has to deal with them, but that might work better than inference variables for various reasons.
4. If there are unproven obligations for an inference variable, fall it back to an opaque type, e.g. turn ?1 into impl Fn(u32) in the above example. This would make these simple cases 'just work', but doesn't really work for more complicated cases where the variable is not the self type of the obligation (e.g. if we have SomeType: Fn(?1) from some function call).

[Veykril]

1. Just keep inference variables, don't do fallback. This would mean we have to deal with them everywhere in the IDE code though, which would be bad.

I wonder, would the IDE code have to specially handle that at all? I'd imagine it wouldn't really change from how we special case unknown types right now either. That is the code that currently checks for unknown would then have to check for inference variables as well and that's it or am I missing something here?