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, types2: spurious compile error when embedding a parameterized type in a struct #44688

Closed
adonovan opened this issue Feb 28, 2021 · 7 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@adonovan
Copy link
Member

adonovan commented Feb 28, 2021

This program (https://go2goplay.golang.org/p/rF1kHzbn4Fc):

type A[T any] struct{}

func (*A[T]) f(T) {}

type B[T any] struct{ A[T] }

func main() {
	var b B[string]
	b.A.f("") // ok
	b.f("") // compile error: type *B[string] of b does not match *A[K] (cannot infer T)
}

causes go2go to emit this spurious-looking error:

prog.go2:12:2: type *B[string] of b does not match *A[T] (cannot infer T)

dev.go2go version 356c171

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 28, 2021
@ianlancetaylor ianlancetaylor added this to the Unreleased milestone Feb 28, 2021
@ianlancetaylor
Copy link
Contributor

Looks like an error in the type checker.

CC @griesemer

@griesemer griesemer self-assigned this Mar 1, 2021
@griesemer griesemer modified the milestones: Unreleased, Go1.17 Mar 1, 2021
@griesemer
Copy link
Contributor

Agreed. This should work.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/298129 mentions this issue: cmd/compile/internal/types2: use correct recv for parameterized embedded methods

@griesemer griesemer changed the title cmd/go2go: spurious compile error when embedding a parameterized type in a struct go/types, types2: spurious compile error when embedding a parameterized type in a struct Mar 3, 2021
@griesemer
Copy link
Contributor

griesemer commented Mar 3, 2021

https://golang.org/cl/298129 fixes this for cmd/compile/internal/types2 and thus the compiler (type checking). Once this is ported to go/types and merged into the dev.go2go branch, it will be fixed there as well (though the actual go2go translator may fail).

@griesemer griesemer added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Mar 3, 2021
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/298349 mentions this issue: go/types: use correct recv for parameterized embedded methods

gopherbot pushed a commit that referenced this issue Mar 3, 2021
…ded methods

Methods of generic types are instantiated lazily (upon use). Thus,
when we encounter a method of such a type, we need to instantiate
the method signature with the receiver type arguments. We infer
those type arguments from the method receiver. If the method is
embedded, we must use the actual embedded receiver type, otherwise
the receiver type declared with the method doesn't match up and
inference will fail.

(Note that there's no type inference in the source code here, it's
only the implementation which uses the existing inference mechanism
to easily identify the actual type arguments. If the implementation
is correct, the inference will always succeed.)

Updates #44688.

Change-Id: Ie35b62bebaeaf42037f2ca00cf8bd34fec2ddd9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/298129
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@findleyr
Copy link
Contributor

findleyr commented Mar 4, 2021

Note that this has not yet been merged to dev.go2go, or deployed to the go2go playground.

I'll update here once this is done.

@findleyr
Copy link
Contributor

findleyr commented Mar 5, 2021

This has been merged and deployed. Now that example just runs into #44689, I believe.

@golang golang locked and limited conversation to collaborators Mar 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants