go/types,types2: unification reached recursion depth limit #59740
Assignees
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
release-blocker
Tools
This label describes issues relating to any tools in the x/tools repository.
Milestone
Comments
gopherbot
added
Tools
|
Thank you for the repro! This appears to still affect go at master. CC @griesemer |
findleyr
added
NeedsInvestigation
findleyr
changed the title
|
Recategorizing as go/types, types2, as this bug is not specific to gopls. |
|
Simpler reproducer: type F[T any] func(func(F[T]))
func f(F[int]) {}
func g[T any](F[T]) {}
func _() {
g(f)
} |
|
Inference trace (with cut-off beyond depth 10):
|
|
Better trace: The question is: should |
|
Change https://go.dev/cl/487197 mentions this issue: |
|
Change https://go.dev/cl/498895 mentions this issue: |
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 <[email protected]> Auto-Submit: Robert Griesemer <[email protected]> Run-TryBot: Robert Griesemer <[email protected]> Reviewed-by: Robert Griesemer <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
gopls version
What did you do?
https://go.dev/play/p/iI-wIjV_gpS
What did you expect to see?
compilation error like
stack overflowWhat did you see instead?
go run main.goprints:gopls crashes with following error:
Editor and settings
VSCode with Go plugin
The text was updated successfully, but these errors were encountered: