go/types, types2: type inference should unify interface types

[cr7pt0gr4ph7]

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

$ go version
go version devel go1.19-5a040c5a36 Thu Mar 10 09:12:04 2022 +0000

Does this issue reproduce with the latest release?

Probably also with 1.18rc1, haven't had a chance to test it yet.

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

Gotip Playground.

What did you do?

Experimenting with type inference and anonymous interface types as constraints and/or inference inputs.

package main

type BasicAnon = interface {
	M() int
}

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

func main() {
	var a BasicAnon
	InferAnon(a) // crash due to this line
	_ = a
}

https://gotipplay.golang.org/p/lJOnm9LexpD

What did you expect to see?

Either a compiler error, or a successful compilation.

What did you see instead?

A compiler crash due to an assertion failure in (*cycleFinder).typ on this line:

case *Signature:
	// There are no "method types" so we should never see a recv.
	assert(t.recv == nil)
	...

The assumption made in the comment is obviously not true with respect to interface method types, for which (*Signature).Recv() is set to the declaring interface's type.

[findleyr]

CC @griesemer

[griesemer]

Conservatively marking as a release blocker.

[griesemer]

Slightly simplified reproducer:

package p

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

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

[cr7pt0gr4ph7]

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.

[griesemer]

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.

[gopherbot]

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

[cr7pt0gr4ph7]

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.

[griesemer]

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

[gopherbot]

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

[griesemer]

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.

[dmitshur]

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.

[findleyr]

Moving to 1.21 as it likely requires a proposal.

[gopherbot]

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

[gopherbot]

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