Diagnostics talk about `fn pointer` when no pointers are in the source

[oli-obk]

Trait function API mismatches (where the impl differs from the declaration) report the correct error about the mismatch, but also give a more detailed note like

  = note: expected fn pointer `fn(&())`
             found fn pointer `fn(())`

This could cause some confusion as the user hasn't done anything with function pointers.

trait Foo {
    fn foo(&self);
}

impl Foo for () {
    fn foo(self) {}
}

(Playground)

Errors:

   Compiling playground v0.0.1 (/playground)
error[E0053]: method `foo` has an incompatible type for trait
 --> src/lib.rs:6:12
  |
2 |     fn foo(&self);
  |            ----- type in trait
...
6 |     fn foo(self) {}
  |            ^^^^ expected `&()`, found `()`
  |
  = note: expected fn pointer `fn(&())`
             found fn pointer `fn(())`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0053`.
error: could not compile `playground`.

To learn more, run the command again with --verbose.

[Centril]

cc @estebank

[estebank]

What are some appropriate wordings? fn signature? fn? fn type? Revert this one back to just type?

[oli-obk]

Maybe without any descriptive word?

  = note: expected `fn(&())`
             found `fn(())`

Is there any particular reason we're displaying the note at all? In the examples I was able to coax out of the compiler the main message was the part that was helpful, the note was just redundant.

[estebank]

This used to be "expected type" which was also confusing when showing things that weren't really something that people associated with types, so it's using the TyKind description now. We could remove it entirely, but I find that having a small level of redundancy in our wording can help introduce and teach concepts to new users. This is why when I saw this I didn't change this to something like "function", but I'm really happy you opened this conversation.

[oli-obk]

This used to be "expected type"

Yea that was quite suboptimal

We could remove it entirely, but I find that having a small level of redundancy in our wording can help introduce and teach concepts to new users

Right, having different verbosity levels for different experience levels is a different discussion, so: more verbosity is better for now. What do you think about

  = note: expected function with signature `fn(&())`
             found function with signature `fn(())`

or does that get too long for complex signatures?

[estebank]

It makes sense but seems a bit long, I wonder if we can simultaneously make it shorter and less "jargony" by doing something like (for fn pointers specifically):

  = note: expected function like `fn(&())`
             found function like `fn(())`

[oli-obk]

Oh yea, that's good

[compiler-errors]

Original problem is fixed by #106131, not sure about the rest of the discussion but probably should be moved to a different issue.