Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

go/types: interface mismatch error message could be more helpful #54942

Closed
kylec1 opened this issue Sep 7, 2022 · 6 comments
Closed

go/types: interface mismatch error message could be more helpful #54942

kylec1 opened this issue Sep 7, 2022 · 6 comments
Assignees
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@kylec1
Copy link

kylec1 commented Sep 7, 2022

What version of Go are you using (go version)?

1.19

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

All

What did you do?

Tried to compile slightly incorrect code.
A staged reproduction of a real case can be seen at https://go.dev/play/p/wU5P93xIA2Q

What did you expect to see?

An error message that helped me identify the specific issue immediately.
In particular, the real world scenario involved some folks used to Rust, and they found it
annoying to have to manually diff the involved arguments when the compiler knew exactly which one
was wrong, and they knew in Rust the specific issue would be clearly highlighted and thus immediately obvious.
Here's an attempted Rust transliteration that shows the error message: https://godbolt.org/z/ncv67o93M

What did you see instead?

An adequate but less helpful than it could be error message.

Go types are generally simpler so there's less need for compiler help (maybe more now with generics), but in cases where the compiler knows exactly which of the 7 or so involved types is wrong by one character, it'd be neat if it could expose that information.

@mdempsky
Copy link
Member

mdempsky commented Sep 8, 2022

The rust compiler's output is:

error[E0053]: method `execute` has an incompatible type for trait
  --> <source>:15:98
   |
15 |     fn execute(context: &Context, stmt: &Stmt, maxrows: i64, args: Vec<String>, urgency: i32) -> Result<Box<Row>, E> {
   |                                                                                                  ^^^^^^^^^^^^^^^^^^^
   |                                                                                                  |
   |                                                                                                  expected struct `Row`, found struct `Box`
   |                                                                                                  help: change the output type to match the trait: `Result<Row, E>`
   |
note: type in trait
  --> <source>:9:98
   |
9  |     fn execute(context: &Context, stmt: &Stmt, maxrows: i64, args: Vec<String>, urgency: i32) -> Result<Row, E>;
   |                                                                                                  ^^^^^^^^^^^^^^
   = note: expected fn pointer `fn(&Context, &Stmt, _, Vec<_>, _) -> Result<Row, _>`
              found fn pointer `fn(&Context, &Stmt, _, Vec<_>, _) -> Result<Box<Row>, _>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0053`.
Compiler returned: 1

@mdempsky mdempsky changed the title compiler: Interface mismatch error message could be more helpful go/types: interface mismatch error message could be more helpful Sep 8, 2022
@mdempsky
Copy link
Member

mdempsky commented Sep 8, 2022

/cc @griesemer @findleyr

@afq984
Copy link

afq984 commented Sep 8, 2022

I think the diff would be more obvious if the parameter names are omitted:

have Execute(context.Context, sql.Stmt, int, []sql.NamedArg, int) (*Result, error)
want Execute(context.Context, sql.Stmt, int, []sql.NamedArg, int) (Result, error)

@mknyszek mknyszek added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 8, 2022
@mknyszek mknyszek added this to the Backlog milestone Sep 8, 2022
@griesemer
Copy link
Contributor

@afq984 agreed. When printing the method signatures, they should both be printed the same way, without parameter names. This would reduce clutter and show the difference right away.

There's more that could be done, but this is an easy an effective fix. I will take care of this.

@griesemer griesemer self-assigned this Sep 9, 2022
@griesemer griesemer modified the milestones: Backlog, Go1.20 Sep 9, 2022
@gopherbot
Copy link

Change https://go.dev/cl/430416 mentions this issue: go/types, types2: don't print function parameter names when showing type differences

@findleyr
Copy link
Contributor

FWIW, I think we should consider doing better here. Compare #54258: I think that it would be useful if the type-checker could report a specific reason why two types are not identical.

@golang golang locked and limited conversation to collaborators Sep 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

7 participants