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

CC @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

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.

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

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.

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.

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

Change https://go.dev/cl/403754 mentions this issue: [release-branch.go1.18] go/types,types2: delay the check for conflicting struct field names