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

[Kobzol]

@rustbot ready

[Kobzol]

Hey errs 👋 Just wanted to ask if I should reroll? I know you have a lot of PRs assigned.

[compiler-errors]

Yeah, actually now that I think of it, I don't think this is the right way of doing it. I don't think we should be creating a new trait ref just to call into the existing code for suggestions -- this probably should be integrated in a more first class way.

I'm on vacation anyways so I will reroll.

@rustbot author
r? compiler

[SparrowLii]

@bors r+

[bors]

📌 Commit 6f1c20d has been approved by SparrowLii

It is now in the queue for this repository.

[SparrowLii]

Yeah, actually now that I think of it, I don't think this is the right way of doing it. I don't think we should be creating a new trait ref just to call into the existing code for suggestions -- this probably should be integrated in a more first class way.

I'm on vacation anyways so I will reroll.

@rustbot author r? compiler

Ah sry that didn't get this in time

@bors r-

[SparrowLii]

I guess the first step should be enhancing the diagnostics when a user has add the Fn-like traits with misused of parameters. Like this:

fn foo<F: Fn(u32, u32) -> u32>(f: F) -> u32 {
    f(1)
}

We can consider suggestions for the Fn-like traits based on scenarios with smaller distance of current implementation.

View changes since this review

[SparrowLii]

There several function traits like Fn, Fnmut or FnOnce. It's hard to know which one is most suitable.

[Kobzol]

My original use-case was that there is no bound at all. In that case, we really can't guess much, I suppose, so using Fn as the most related option seemed reasonable to me.

[Kobzol]

I think that the diagnostics for that are already pretty good:

   Compiling playground v0.0.1 (/playground)
error[E0057]: this function takes 2 arguments but 1 argument was supplied
 --> src/main.rs:2:5
  |
2 |     f(1)
  |     ^--- argument #2 of type `u32` is missing
  |
note: callable defined here
 --> src/main.rs:1:11
  |
1 | fn foo<F: Fn(u32, u32) -> u32>(f: F) -> u32 {
  |           ^^^^^^^^^^^^^^^^^^^
help: provide the argument
  |
2 |     f(1, /* u32 */)
  |        +++++++++++

I was specifically aiming at the use-case where the bound doesn't contain Fn already.

[SparrowLii]

I think that the diagnostics for that are already pretty good:

   Compiling playground v0.0.1 (/playground)
error[E0057]: this function takes 2 arguments but 1 argument was supplied
 --> src/main.rs:2:5
  |
2 |     f(1)
  |     ^--- argument #2 of type `u32` is missing
  |
note: callable defined here
 --> src/main.rs:1:11
  |
1 | fn foo<F: Fn(u32, u32) -> u32>(f: F) -> u32 {
  |           ^^^^^^^^^^^^^^^^^^^
help: provide the argument
  |
2 |     f(1, /* u32 */)
  |        +++++++++++

I was specifically aiming at the use-case where the bound doesn't contain Fn already.

We can think of suggesting F: Fn(u32) -> u32 instead of providing the argument here. However, this suggestion probably be inappropriate, as it is very likely to be a typeck error in statements where foo are called.

So maybe we can lift the suggestion of this PR to statements which calling foo and use type of the argument be provided. In this way we may avoid to make a new trait_ref

[Kobzol]

So maybe we can lift the suggestion of this PR to statements which calling foo and use type of the argument be provided. In this way we may avoid to make a new trait_ref

Sorry, I didn't understand that suggestions. Nor do I fully grok what Michael originally meant 😆 I probably don't have enough experience with this subsystem to suggest a more "first-class" solution.

[bors]

☔ The latest upstream changes (presumably #145993) made this pull request unmergeable. Please resolve the merge conflicts.