CC @griesemer

Conservatively marking as a release blocker.

Slightly simplified reproducer:

package p

func f[P interface{ m() R }, R any](P) {}

func _() {
	var x interface { m() int }
	f(x)
}

I've been experimenting a bit, and made the following discoveries (using a modified version of go/types):

• After disabling the assertion, the example code given above causes the compiler error cannot infer R, as should probably be expected.

• But the following code then infers & typechecks without problems, although it ought not to, given my current understanding of the intended behavior of type inference (cmd/compile (types2, go/types): cannot infer generic interface types #41176):

package main

type BasicAnon = interface {
	M() int
}

func InferAnon[I []interface{ M() R }, R any](arg I) {
}

func main() {
	var a []BasicAnon
	InferAnon(a)
	_ = b
}

So, it seems that the implementation already kind-of supports type inference via interface methods, probably as an artifact of the unification algorithm mirroring the type equality/assignability algorithm.

The assertion is clearly wrong and needs to be removed - we can see signatures of interface methods in that code. The constraint type inference fails at the moment for R because there's no "core term" in this case (implementation-wise). I have a 3-line fix but I am not confident yet that it is correct under all circumstances.

In any case, thanks for this bug report. At the very least we will address the crash for 1.18.

Change https://go.dev/cl/391615 mentions this issue: go/types, types2: remove incorrect assertion (don't crash)

As mentioned above, I'd caution that it seems that the generics type checking code currently is a bit inconsistent in that it allows unification of some constructs (e.g. []interface{M() int} unifies with []interface{M() R} (with R unified to int), but interface{M() int} does not unify with interface{M() R}). The spec isn't very clear in this regard, except for the definition of "(adjusted) core type", which disallows the latter, and kind of allows the former by bot expressly forbidding it.

How bad this is with respect to the release depends on whether such "structural inference" (for the lack of a better word) for interfaces is intended to be allowed in the future for all cases, or forbidden for all cases. In the former case, one should probably also allow unification of interface{M() int;N()} with interface{M() T} during constraint type inference.

I've played around a bit at https://github.com/cr7pt0gr4ph7/go-types-experiments and https://gotipplay.golang.org/p/W-HYHRcmIXD and got the extended inference to work quite trivially, but that is definitely out of scope for this issue.

The spec section on type inference will eventually need to be refined/rewritten. We're not going to change anything else here besides fixing the crash for 1.18. As long as we are not inferring incorrect types, we're ok. Eventually we would like to infer these "obvious" cases. As a consequence, code that may not be valid now (inference fails) may become valid in the future (which is ok), but hopefully not the other war around (which would not be ok).

Change https://go.dev/cl/391796 mentions this issue: [release-branch.go1.18] go/types, types2: remove incorrect assertion (don't crash)

Once this is cherry-picked into the 1.18 release branch, this is not a release blocker anymore and can be marked for Go 1.19.

The cherry-pick commit 8706c09 (CL 391796) has landed on release-branch.go1.18.
Per comment above, removing release-blocker and moving to Go1.19 milestone.

Moving to 1.21 as it likely requires a proposal.

Change https://go.dev/cl/472298 mentions this issue: go/types, types2: consider methods when unifying type parameters and constraints

Change https://go.dev/cl/499282 mentions this issue: doc/go1.21: document type inference changes