cmd/go2go: newtype of constraint causes endless recursion

[tdakkota]

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

$ go version
go version devel +34f76220c3 Sat Jul 4 04:55:49 2020 +0000 windows/amd64

Does this issue reproduce with the latest release?

n/a

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

• Go2go playground
• windows/amd64

What did you do?

https://go2goplay.golang.org/p/mSgtHY8Dv7v

What did you expect to see?

Successful compilation or error like

prog.go2:3:6: illegal cycle in declaration of K
prog.go2:3:6: 	K refers to
prog.go2:3:6: 	K 

What did you see instead?

Partial stack trace:

goroutine 1 [running]:
go/types.(*subster).func_(0xc020161780, 0xc0000411d0, 0x0)
	G:/workspace/exprm/go/src/go/types/subst.go:489 +0x165 fp=0xc020161370 sp=0xc020161368 pc=0xe6d265
go/types.(*subster).funcList(0xc020161780, 0xc000006048, 0x1, 0x1, 0x0, 0x0, 0x0, 0x0)
	G:/workspace/exprm/go/src/go/types/subst.go:503 +0xa5 fp=0xc0201613e0 sp=0xc020161370 pc=0xe6d325
go/types.(*subster).typ(0xc020161780, 0xff10c0, 0xc00010a080, 0x0, 0x0)
	G:/workspace/exprm/go/src/go/types/subst.go:302 +0x177e fp=0xc020161758 sp=0xc0201613e0 pc=0xe6bede
go/types.(*Checker).subst(0xc0001045a0, 0x4a, 0xff10c0, 0xc00010a080, 0xc0078aa520, 0x1, 0xc0078aa520)
	G:/workspace/exprm/go/src/go/types/subst.go:230 +0x12b fp=0xc0201617b0 sp=0xc020161758 pc=0xe6a6cb
go/types.(*Checker).instantiate(0xc0001045a0, 0x45, 0xff1200, 0xc00007e240, 0xc0000325e0, 0x1, 0x1, 0xc00000a520, 0x1, 0x1, ...)
	G:/workspace/exprm/go/src/go/types/subst.go:139 +0x2aa fp=0xc0201619a8 sp=0xc0201617b0 pc=0xe6974a
go/types.(*instance).expand(0xc00003e480, 0x0, 0x0)
	G:/workspace/exprm/go/src/go/types/type.go:938 +0xb1 fp=0xc020161a18 sp=0xc0201619a8 pc=0xe70611
go/types.(*instance).Named(0xc00003e480, 0x8)
	G:/workspace/exprm/go/src/go/types/type.go:929 +0x32 fp=0xc020161a40 sp=0xc020161a18 pc=0xe70492
go/types.(*Named).Under(0xc00007e2d0, 0x0, 0x0)
	G:/workspace/exprm/go/src/go/types/decl.go:498 +0x6e fp=0xc020161c10 sp=0xc020161a40 pc=0xe3b28e
go/types.(*Named).TypeParam(0xc00007e2d0, 0x0)
	G:/workspace/exprm/go/src/go/types/type.go:791 +0x32 fp=0xc020161c38 sp=0xc020161c10 pc=0xe6f5d2
go/types.(*Checker).instantiate(0xc0001045a0, 0x45, 0xff1200, 0xc00007e240, 0xc0000325e0, 0x1, 0x1, 0xc00000a520, 0x1, 0x1, ...)
	G:/workspace/exprm/go/src/go/types/subst.go:150 +0x84f fp=0xc020161e30 sp=0xc020161c38 pc=0xe69cef
go/types.(*instance).expand(0xc00003e480, 0x0, 0x0)
	G:/workspace/exprm/go/src/go/types/type.go:938 +0xb1 fp=0xc020161ea0 sp=0xc020161e30 pc=0xe70611
go/types.(*instance).Named(0xc00003e480, 0x8)
	G:/workspace/exprm/go/src/go/types/type.go:929 +0x32 fp=0xc020161ec8 sp=0xc020161ea0 pc=0xe70492
go/types.(*Named).Under(0xc00007e2d0, 0x0, 0x0)
	G:/workspace/exprm/go/src/go/types/decl.go:498 +0x6e fp=0xc020162098 sp=0xc020161ec8 pc=0xe3b28e
go/types.(*Named).TypeParam(0xc00007e2d0, 0x0)
	G:/workspace/exprm/go/src/go/types/type.go:791 +0x32 fp=0xc0201620c0 sp=0xc020162098 pc=0xe6f5d2
go/types.(*Checker).instantiate(0xc0001045a0, 0x45, 0xff1200, 0xc00007e240, 0xc0000325e0, 0x1, 0x1, 0xc00000a520, 0x1, 0x1, ...)
	G:/workspace/exprm/go/src/go/types/subst.go:150 +0x84f fp=0xc0201622b8 sp=0xc0201620c0 pc=0xe69cef
go/types.(*instance).expand(0xc00003e480, 0x0, 0x0)
...

[thepudds]

Hi @tdakkota, thanks for filing this. There is some chance what you found is similar to Crash 22 in #39634 (comment).

Crash 22 there also seemed to be endless recursion, and comparing the partial trace you posted here with the call stack there, they both seem to follow a similar pattern of:

go/types.(*instance).expand-> instantiate -> TypeParam -> Under -> Named -> expand -> instantiate -> ...

That said, I'm not sure if they are the same underlying problem, and I think you are more likely than me to know whether or not they are the same. ;-)

cc @griesemer

[gopherbot]

Change https://golang.org/cl/241037 mentions this issue: [dev.go2go] go/types: avoid endless recursion in self-recursive newty…

[griesemer]

This was fixed in the type checkers with the above CL.

For

package p

type comp[T comparable] T
type K comp[K] // becomes 'type K K', where K is comparable

the reported error is now:

$ go tool compile -G=3 x.go2
x.go2:4:6: invalid recursive type K
	x.go2:4:6: K refers to
	x.go2:4:8: comp refers to
	x.go2:4:6: K