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

cmd/compile: unhelpful error message with recursive constraint #61685

Open
rogpeppe opened this issue Aug 1, 2023 · 4 comments
Open

cmd/compile: unhelpful error message with recursive constraint #61685

rogpeppe opened this issue Aug 1, 2023 · 4 comments
Assignees
Labels
BadErrorMessage Issues related compiler error messages that should be better. compiler/runtime Issues related to the Go compiler and/or runtime. generics Issue is related to generics NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. TypeInference Issue is related to generic type inference
Milestone

Comments

@rogpeppe
Copy link
Contributor

rogpeppe commented Aug 1, 2023

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

$ go version
go version devel go1.21-af8f94e3c5 Tue Jul 11 21:30:51 2023 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

N/A

What did you do?

https://go.dev/play/p/WWBorJLIgwe?v=gotip

package main

func main() {}

func New[T any](x any) {
	f(x.(I[T]))
}

func f[T I[T]](t T) {}

type I[T any] interface {
	M(t T)
}

What did you expect to see?

A more helpful error message.

What did you see instead?

./prog.go:6:3: T (type I[T]) does not satisfy I[T] (wrong type for method M)
		have M(T)
		want M(T)

AIUI, the actual error stems from the fact that the receiver type does not match the type in the method argument, but the error message only includes the method signature, which makes it hard to see what the actual problem is, particular in the context of a much larger program.

@rogpeppe rogpeppe added generics Issue is related to generics compiler/runtime Issues related to the Go compiler and/or runtime. labels Aug 1, 2023
@rogpeppe
Copy link
Contributor Author

rogpeppe commented Aug 1, 2023

@griesemer

@griesemer griesemer self-assigned this Aug 1, 2023
@griesemer griesemer added this to the Go1.22 milestone Aug 1, 2023
@griesemer griesemer added TypeInference Issue is related to generic type inference NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Aug 1, 2023
@griesemer
Copy link
Contributor

Manually instantiating (rather than relying on type inference) the call of f exposes the problem:

func New[T any](x any) {
	f[I[T]](x.(I[T])) // <<< manual instantiation
}

func f[T I[T]](t T) {}

type I[T any] interface {
	M(t T)
}

The error is:

testdata/manual.go:11:4: I[T] does not satisfy I[I[T]] (wrong type for method M)
                        have M(T)
                        want M(I[T])

Agreed that we need to find a better way to report this.

@griesemer griesemer added the BadErrorMessage Issues related compiler error messages that should be better. label Dec 11, 2023
@gopherbot
Copy link

Change https://go.dev/cl/549296 mentions this issue: go/types, types2: avoid confusing error message "have m(T), want m(T)"

@griesemer
Copy link
Contributor

Stop-gap solution in place for now. Moving to 1.23.

@griesemer griesemer modified the milestones: Go1.22, Go1.23 Dec 12, 2023
gopherbot pushed a commit that referenced this issue Dec 13, 2023
This is a partial fix for situations where a method lookup leads to
an error due to non-matching signatures, but where the signatures
print exactly the same. This can happen if both signatures contain
type parameters (after instantiation) and the type parameters have
the same name (such as "T").

For now, rather than printing a confusing error message in this
case, leave away the confusing part of the error message (at the
cost of providing slightly less information).

In the long run, we need to find a better solution for this problem;
but this seems better than what we had before.

For #61685.

Change-Id: I259183f08b9db400ffc8e1cf447967c640a0f444
Reviewed-on: https://go-review.googlesource.com/c/go/+/549296
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
ezz-no pushed a commit to ezz-no/go-ezzno that referenced this issue Feb 18, 2024
This is a partial fix for situations where a method lookup leads to
an error due to non-matching signatures, but where the signatures
print exactly the same. This can happen if both signatures contain
type parameters (after instantiation) and the type parameters have
the same name (such as "T").

For now, rather than printing a confusing error message in this
case, leave away the confusing part of the error message (at the
cost of providing slightly less information).

In the long run, we need to find a better solution for this problem;
but this seems better than what we had before.

For golang#61685.

Change-Id: I259183f08b9db400ffc8e1cf447967c640a0f444
Reviewed-on: https://go-review.googlesource.com/c/go/+/549296
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BadErrorMessage Issues related compiler error messages that should be better. compiler/runtime Issues related to the Go compiler and/or runtime. generics Issue is related to generics NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. TypeInference Issue is related to generic type inference
Projects
Development

No branches or pull requests

3 participants