go/types, types2: type inference should report a better error message

[eliben]

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

$  gotip version
go version devel go1.18-fe8347b Fri Sep 24 10:51:48 2021 +0000 linux/amd64

What did you do?

Trying to compile this sample: https://go2goplay.golang.org/p/MAplKhfhuKs

What did you expect to see?

The sample is incomplete (I tried to minimize it), so I don't expect it to compile. At the very least, there are calls to functions that don't exist.

The code is also incorrect. In the signature of quickSort_gen_func, a, b should be int, not Elem. Fixing this, the compiler produces an expected error message instead of going into infinite recursion.

What did you see instead?

runtime: goroutine stack exceeds 1000000000-byte limit
runtime: sp=0xc0205e0318 stack=[0xc0205e0000, 0xc0405e0000]
fatal error: stack overflow

runtime stack:
runtime.throw(0x6aa2fc, 0xe)
	/usr/local/go-faketime/src/runtime/panic.go:1126 +0x74
runtime.newstack()
	/usr/local/go-faketime/src/runtime/stack.go:1069 +0x7de
runtime.morestack()
	/usr/local/go-faketime/src/runtime/asm_amd64.s:436 +0x8b

goroutine 1 [running]:
go/types.(*unifier).nifyEq(0xc00058a140, 0x6f32a0, 0xc0000105a0, 0x6f30e8, 0x817000, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/unify.go:197 +0xb8 fp=0xc0205e0328 sp=0xc0205e0320 pc=0x5a6c18
go/types.(*unifier).nify(0xc00058a140, 0x6f32a0, 0xc0000105a0, 0x6f30e8, 0x817000, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/unify.go:238 +0x10f6 fp=0xc0205e0488 sp=0xc0205e0328 pc=0x5a7d16
go/types.(*unifier).nifyEq(0xc00058a140, 0x6f32a0, 0xc0000105a0, 0x6f30e8, 0x817000, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/unify.go:198 +0x70 fp=0xc0205e04d0 sp=0xc0205e0488 pc=0x5a6bd0
go/types.(*unifier).nify(0xc00058a140, 0x6f32a0, 0xc0000105a0, 0x6f30e8, 0x817000, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/unify.go:238 +0x10f6 fp=0xc0205e0630 sp=0xc0205e04d0 pc=0x5a7d16
...
<SNIP>

[griesemer]

Smaller reproducer:

package p

func f[P any](a, _ P) {
	f(a, int(0))
}

Compiling leads to an infinite recursion in type inference.

[gopherbot]

Change https://golang.org/cl/352832 mentions this issue: cmd/compile/internal/types2: avoid infinite recursion in unification

[gopherbot]

Change https://golang.org/cl/353029 mentions this issue: go/types: avoid infinite recursion in unification

[gopherbot]

Change https://golang.org/cl/354690 mentions this issue: cmd/compile/internal/types2: fix unification (again)

[griesemer]

The previous fix attempt was incorrect. Re-opening.

[cherrymui]

Any update on this? Thanks.
(checking in as this is a release blocker.)

[findleyr]

I de-duped #50273 to this issue. Once this is fixed we should confirm that it also resolves the repro there.

[gopherbot]

Change https://golang.org/cl/377954 mentions this issue: go/types, types2: prevent unification from recursing endlessly

[griesemer]

With the above CL this doesn't crash anymore. Still needs a proper fix but not a release blocker anymore.

[gopherbot]

Change https://golang.org/cl/381274 mentions this issue: slices: relax the constraints to type whose underlying type is slice

[griesemer]

This produces an ok error message and doesn't crash. Leaving for 1.19.

[gopherbot]

Change https://go.dev/cl/385494 mentions this issue: go/types, types2: avoid infinitely recursive instantiation

[griesemer]

The type inference algorithm doesn't run into endless recursions anymore since 1.18, and for 1.19 we have disabled the catch-all in case of an infinite recursion and haven't seen any problems so far.

For the simple reproducer

package p

func f[P any](a, _ P) {
	f(a, int(0))
}

the error message is:

testdata/manual.go:4:7: type int of int(0) does not match inferred type P for P

which is exactly right (barring more information, the 2nd argument's type must be P) , and at the correct location.

There's nothing else to do here for now. Closing.