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
Assignees
Labels
Milestone

Comments

@adonovan
Copy link
Contributor

@adonovan 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
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 28, 2021

Looks like an error in the type checker.

CC @griesemer

Loading

@griesemer griesemer self-assigned this Mar 1, 2021
@griesemer griesemer removed this from the Unreleased milestone Mar 1, 2021
@griesemer griesemer added this to the Go1.17 milestone Mar 1, 2021
@griesemer
Copy link
Contributor

@griesemer griesemer commented Mar 1, 2021

Agreed. This should work.

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 3, 2021

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

Loading

@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 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).

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 3, 2021

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

Loading

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>
@gopherbot gopherbot closed this in 12bb256 Mar 4, 2021
@findleyr
Copy link
Contributor

@findleyr 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.

Loading

@findleyr
Copy link
Contributor

@findleyr findleyr commented Mar 5, 2021

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

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants