go/types: missing type information in cycle detection

[cuonglm]

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

$ go version
go version devel +816ff44479 Tue Oct 8 16:41:02 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env

What did you do?

package p

type I1 = interface {
	I2
}

type I2 interface {
	I1
}

What did you expect to see?

Run gotype built with go1.13.x for above program print:

issue23823.go:13:6: illegal cycle in declaration of I2
issue23823.go:13:6: 	I2 refers to
issue23823.go:9:6: 	I1 refers to
issue23823.go:13:6: 	I2

What did you see instead?

With go1.14.x, go1.15.x and tip:

issue23823.go:13:6: illegal cycle in declaration of I2
issue23823.go:13:6: 	I2 refers to
issue23823.go:13:6: 	I2

git bisect points to 37a2290

cc @griesemer @mdempsky

[griesemer]

cc @findleyr

[gopherbot]

Change https://golang.org/cl/258177 mentions this issue: cmd/compile: report type loop for invalid recursive types

[griesemer]

For type aliases we don't keep the names around which is (likely) the cause for this issue. That is, for the type-checker, the type I2 looks like this:

type I2 interface {
    interface {
        I2
    }
}

and eventually like this

type I2 interface {
    I2
}

which explains the error message.

Fixing this (and other related issues) requires that we keep alias type names around in some way. That may be a fairly significant change.

[cuonglm]

@griesemer Thanks for details explanation, I don't know that go/types also don't record alias name like cmd/compile. But my concern is that in go1.13.x, we does report alias name in the cycle. Is the behavior change intentional in go1.14.x and above?

[gopherbot]

Change https://golang.org/cl/259447 mentions this issue: go/types: introduce an interstitial typeAlias Type

[findleyr]

https://golang.org/cl/259447 proposes one way to solve this: by preserving type alias information in the type graph until the last possible moment. This is achieved by introducing a typeAlias Type for internal use only, and 'collapsing' this type at API boundaries.

The other thing I tried was to preserve syntactic cycle information in, for example, a Checker.cycles map, so that we can accurately report all the edges in our cycle when it is later discovered to be invalid. This proved to be quite complex though, because it's not trivial to reverse-engineer the syntactic cycle that corresponds to a type cycle (consider the case where we have a deep, high degree graph of type aliases).

The downside of CL 259447 is that we have to be very careful not to leak the typeAlias type. There are some things we could do to make this safer, for example introducing a new type to mean "all Types plus aliases", but such a change would turn out to be quite large and I don't want to embark on this without discussing with @griesemer.

[cuonglm]

gotip now produces shorter error:

$ go version 
go version devel go1.20-d5de62df15 Thu Nov 24 06:48:07 2022 +0000 linux/amd64
$ go tool compile p.go 
p.go:7:6: invalid recursive type: I2 refers to itself

While go1.19 still uses old error message:

$ go1.19.3 tool compile p.go 
p.go:7:6: invalid recursive type I2
	p.go:7:6: I2 refers to
	p.go:7:6: I2

[cuonglm]

Both gotype and the compiler now produce meaningful message.

$ go1.20.5 tool compile pp.go 
pp.go:7:6: invalid recursive type: I2 refers to itself