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

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.

@estebank

cc @estebank

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

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.

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.

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?

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(())`

Oh yea, that's good

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

Rollup merge of rust-lang#106131 - compiler-errors:not-ptrs, r=davidtwco

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

Centril commented on Dec 14, 2019

estebank commented on Dec 14, 2019

oli-obk commented on Dec 14, 2019

estebank commented on Dec 15, 2019

oli-obk commented on Dec 15, 2019

estebank commented on Dec 15, 2019

oli-obk commented on Dec 15, 2019

compiler-errors commented on Jan 7, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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