cmd/compile: does not match inferred type #60460
Assignees
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
NeedsFix
The path to resolution is known, but the work has not been done.
release-blocker
Milestone
Comments
gopherbot
added
the
compiler/runtime
|
The test cases compiles and runs with Go 1.20, but not with current HEAD. It does build with a compiler of a week or two ago. Also the error messages don't make a great deal of sense. Marking as a release blocker. |
ianlancetaylor
added
the
NeedsInvestigation
|
Simplified reproducer: package p
func _() {
f(R1{})
f(R2{})
}
type S[T any] struct {
rules R[T]
}
func f[T any](rules R[T]) {}
func (s S[T]) _() {
f(s.rules)
}
type R[T any] interface {
m(R[T])
}
type R1 struct{}
func (R1) m(R[int]) {}
type R2 struct{}
func (R2) m(R[string]) {}This is related to CL 498315 (submitted yesterday) which addressed issue #60377 (which I believe was a bug). Thus, I am not convinced that the code here is correct. Will think some more over the next few days. |
griesemer
added
NeedsDecision
|
Reduced to one (representative) error: package p
func _() {
f(R1{})
}
func f[T any](R[T]) {}
type R[T any] interface {
m(R[T])
}
type R1 struct{}
func (R1) m(R[int]) {} |
|
Analysis: We're ending up in an endless recursion because we don't use exact unification when comparing component types (e.g. signature elements in this case). It would be good to fix the underlying problem here rather than roll back CL 498315. |
|
Change https://go.dev/cl/498895 mentions this issue: |
|
Change https://go.dev/cl/498955 mentions this issue: |
griesemer
added
NeedsFix
gopherbot
pushed a commit
that referenced
this issue
May 30, 2023
This change defines two unification modes used to control unification: - assign set when unifying types involved in an assignment - exact if set, types unify if they can be made identical Currently, unification is inexact: when a defined type is compared against a type literal, the underlying type of the defined type is considered. When channel types are compared, the channel direction is ignored. And when defined types are compared where one (or both) are interfaces, interface unification is used. By contrast, exact unification requires types to match exactly: if they can be unified, the types must be identical (with suitable type arguments). Exact unification is required when comparing component types. For instance, when unifying func(x P) with func(x Q), the two signatures unify only if P is identical to Q per Go's assignment rules. Until now we have ignored exact unification and made due with inexact unification everywhere, even for component types. In some cases this led to infinite recursions in the unifier, which we guarded against with a depth limit (and unification failure). Go's assignmemt rules allow inexact matching at the top-level but require exact matching for element types. This change passes 'assign' to the unifier when unifying parameter against argument types because those follow assignment rules. When comparing constraints, inexact unification is used as before. In 'assign' mode, when comparing element types, the unifyier is called recursively, this time with the 'exact' mode set, causing element types to be compared exactly. If unification succeeds for element types, they are identical (with suitable type arguments). This change fixes #60460. It also fixes a bug in the test for issue #60377. We also don't need to rely anymore on the recursion depth limit (a temporary fix) for #59740. Finally, because we use exact unification when comparing element types which are channels, errors caused by assignment failures (due to inexact inference which succeeded when it shouldn't have) now produce the correct inference error. Fixes #60460. For #60377. For #59740. Change-Id: Icb6a9b4dbd34294f99328a06d52135cb499cab85 Reviewed-on: https://go-review.googlesource.com/c/go/+/498895 Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
No, tip only.
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
https://go.dev/play/p/3wuGsYeb_DI
What did you expect to see?
compile succeeds
What did you see instead?
Might be related #60377 and 1dd24d8
Same error occurs in https://github.com/zclconf/go-cty with tip.
I couldn't verbalize the title of the issue well. I would appreciate if someone could correct it.
The text was updated successfully, but these errors were encountered: