go/types, types2: correctly handle some recursive constraint type inference cases - don't bail out

[findleyr]

Reminder issue: when type checking recursive function instances that use constraint type inference, we need to either succeed or produce a useful message. For example:

package p

func f[P interface{*Q}, Q any](p P, q Q) {
	_ = f[P]  // case 1
        _ = f[*P]  // case 2
}

Case 1 currently fails with stack overflow (see also #48619), and case 2 fails with a not-very-useful error message ("cannot infer P ([ ])").

CC @griesemer

[griesemer]

Related: Sometimes we get fairly different error messages for different orders of parameters and arguments - i.e., the error depends on which type is inferred first. It would be good to be independent of that order.

[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)

[cherrymui]

Any update on this? Is there anything still need to be done after the CLs above? (The original example still falls into infinite recursion.) Thanks.
(checking in as this is a release blocker.)

[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.

[griesemer]

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

[gopherbot]

Change https://go.dev/cl/385494 mentions this issue: go/types: prototype for eliminating recursive type parameters in