Suggest adding Fn bound when calling a generic parameter

[Kobzol]

The goal of the PR is to provide this diagnostic hint:

fn foo<T>(t: T) {
    let x: u32 = t(1);
}
//vvv
fn foo<T: Fn(i32) -> u32>(t: T) {
    let x: u32 = t(1);
}

I had to provide some input for suggest_restricting_param_bound, but I wasn't sure where to get the corresponding Fn trait for, because here it didn't seem like the code was already checking for trait impl matches, unlike e.g. in check_overloaded_binop, where the suggest function is also used. With the help of Claude, I managed to create the trait ref somehow, but I'm not at all sure if it's the right way to do (in particular around Binder::dummy).

The suggest_restricting_param_bound change is also super hacky - maybe there's a way to "attach" the associated Output type to the Fn trait ref, so that we don't have to manually render the output type?

[rustbot]

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[compiler-errors]

r? compiler-errors @bors r+ rollup

[bors]

📌 Commit 9ff1376 has been approved by compiler-errors

It is now in the queue for this repository.

[fmease]

CI is red (not just spellcheck) @bors r-

[compiler-errors]

oops :D

[Kobzol]

|

• help: consider restricting type parameter U with trait Fn
• |
• LL | fn foo<U: Fn() -> _>(t: U) {

The suggestion here is valid, but since the return type is unknown (-> _), the suggestion ofc won't compile. And since we use MachineApplicable for this, maybe we should skip the return value if it is an unknown type? I tried to do that (not sure if ty.has_infer() is the right way to detect _ though).

@rustbot ready