-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: "panic: unification reached recursion depth limit" with recursive type constraint #67627
Comments
Slightly simplified reproducer: package p
type S *S
func f[R, T *R](T) {}
func _() {
var s S
f(s)
} panics as described. But adding a package p
type S *S
func f[R, T ~*R](T) {} // <<< no crash with `~`
func _() {
var s S
f(s)
} |
The handling of type element unification may not be quite right (see unify.go:566 ff.) Too late to fix for 1.23 as this is tricky and may introduce subtle bugs. |
@taking and I looked at this some more. At the core of the issue we have the following situation.
From the inference trace:
It's not obvious what the correct "fix" is in a case like this. We end up in a cycle because of the cyclic definition of One approach might be to start with type parameters for which we already have a type argument inferred when doing the constraint type inference step. |
This issue is currently labeled as early-in-cycle for Go 1.24. |
Moving to 1.25; too late for 1.24. |
This issue is currently labeled as early-in-cycle for Go 1.25. |
Go version
go version go1.22.3 darwin/arm64
Output of
go env
in your module/workspace:What did you do?
https://go.dev/play/p/_dEZsvc-bV-
What did you see happen?
<unknown line number>: internal compiler error: panic: unification reached recursion depth limit
What did you expect to see?
I expected a non-panic compilation error.
(But maybe I shouldn't have; with a couple of tweaks, a similar program is valid: https://go.dev/play/p/jJ8fTc7Uhie)
The text was updated successfully, but these errors were encountered: