cmd/compile: cannot convert v (variable of type *Bar[T]) to type *Foo[T]

[b97tsk]

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

$ go version
go version go1.18.1 windows/amd64

Does this issue reproduce with the latest release?

Yes.

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

Irrelevant.

What did you do?

package main

type Foo[T any] struct {
	_ *Bar[T]
}

type Bar[T any] Foo[T]

func (v *Bar[T]) M() {
	_ = (*Foo[T])(v)
}

func main() {}

What did you expect to see?

The code compiles.

What did you see instead?

main.go:10:16: cannot convert v (variable of type *Bar[T]) to type *Foo[T]

The code does compile if the compiler sees type Bar first.

[ianlancetaylor]

It does seem that the behavior changes based on the location of the line type Bar .... That can't be right.

CC @griesemer

[griesemer]

Changing the M method to a function also makes it work:

// func (v *Bar[T]) M() {
// 	_ = (*Foo[T])(v)
// }

func _[T any](v *Bar[T]) {
	_ = (*Foo[T])(v)
}

Definitely a bug. Possibly some bad interaction with method type parameter instantiation/renaming.
cc @findleyr

[findleyr]

We tracked it down. The issue is that with this set-up, the call to under() in the sanity here is happening eagerly, when it should be lazy:
https://cs.opensource.google/go/go/+/master:src/go/types/decl.go;l=715;drc=f2cdc6d1672fb335ac56f9c7b824071f1e5ba545

This can be easily fixed by deferring this sanity check, but it does of course beg the question of how to make the type-checker less sensitive to accidental eager evaluation. For long-term maintainability, we must introduce invariants that allow us to detect or even prevent such bugs.

[findleyr]

@gopherbot, please open a backport issue for 1.18, this is a bug causing valid code not to compile.

[gopherbot]

Backport issue(s) opened: #52558 (for 1.18).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[findleyr]

This turned out not to be entirely trivial, so I will fix it later this week.

The root cause of the problem is that when we collect a methods, we check that method names are unique among existing methods and fields before adding each method. As a result, we have an invariant that recorded method names are always unique among methods and fields. But enforcing this invariant results in us expanding underlying types too soon, before they are fully set-up.

[gopherbot]

Change https://go.dev/cl/403455 mentions this issue: go/types: delay check for duplicate struct field names