go/types, types2: suboptimal error message for instantiated layout cycles

[mrkfrmn]

I was poking around in the type checker and discovered this:

type t[p any] struct {
	f p
}

type a t[a]

Which yields:

./prog.go:7:6: invalid recursive type a
	./prog.go:7:6: a refers to t
	./prog.go:7:8: t refers to a

Which seems a bit confusing as t is generic and makes no reference to a in its definition. I would have expected t[a] refers to a and such.

If we make the type argument an alias, we also do not mention the alias:

type t[p any] struct {
	f p
}

type b = a
type a t[b]

./prog.go:8:6: invalid recursive type a
	./prog.go:8:6: a refers to t
	./prog.go:8:8: t refers to a

I would have expected a t[b] refers to b and b refers to a.

[gabyhelp]

Related Issues

• go/types, types2: bad error message for cycles through type instantiation #74725
• go/types: improve recursive type error message #69574 (closed)
• cmd/compile: handle alias types in recursive types more consistently #50729 (closed)
• cmd/compile: "invalid recursive type" error is not as helpful as go/types #41575 (closed)
• types2, go/types: need to detect invalid recursive type instantiation #48098 (closed)
• go/types: inconsistent type checking results with recursive aliases on 1.22 and 1.23 #70230 (closed)
• go/types, cmd/compile: "invalid type loop" depending on declaration order #51244
• go/types: discrepancy in type checking compared to types2 #67436 (closed)
• gccgo: internal compiler error with simple recursive type declaration #25320 (closed)

Related Code Changes

• cmd/compile: make invalid recursive type error clearer

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}