Related: #45550.

Related: #48096.

This was just reported again in #48671, though in that case the recursion was through a method.

I don't think the same restriction should apply to methods. Consider the following:

func (*List[T]) ToInterfaceList() *List[interface{}]

Somewhat contrived, but one can imagine how something like this could be useful. Perhaps we need logic to detect infinitely expanding instantiation patterns.

I opened #48703 for infinite recursion through method signatures. It is similar to this issue but requires a different fix.

Also marking this issue as a release blocker.

Here's an example that hangs the compiler, but I can't work out if it's covered by this issue or not:

https://go2goplay.golang.org/p/3kUZ6L8amfd

func f[T any](n int) interface{} {
	if n > 0 {
		return f[*T](n - 1)
	}
	return *new(T)
}

@rogpeppe I think that's covered by #48018 and #48711: the *T pattern in your function body expands infinitely.

In https://github.com/mdempsky/nomono, I've implemented a prototype of a check to detect non-monomorphizable type parameter cycles. It constructs a weighted graph representing data flow between type parameters (so really "type flow"). A zero-weight edge indicates that one type parameter is directly used to instantiate another (e.g., f[T]), whereas a positive-weight edge is used to indicate that a derived type is used (e.g., f[*T]). A package is rejected as non-monomorphisable if there are any positive cycles in the resulting graph.

I think this matches the "nomono" predicate from the Featherweight Go paper based on my intuitive understanding of their approach, but I don't fully understand the details of their algorithm so maybe I'm missing a detail. Though regardless, their algorithm doesn't need to worry about details like local types or nested generics.

I plan to write some more tests for it and optimize it, then perhaps we can consider incorporating it into go/types and types2.

Change https://golang.org/cl/357449 mentions this issue: go/types: add check that code is monomorphizable

Change https://golang.org/cl/360857 mentions this issue: cmd/compile/internal/types2: port nomono check from go/types

@rogpeppe The compiler reports an error now for your example.

More generally, this general issue seems to have been addressed with the new nomono check in the type checkers. I believe @mdempsky wanted to add some more tests, so leaving this open for now but not a release blocker anymore.

I am going to close this as fixed at this point.