Skip to content
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

go/types, types2: handle recursive constraint type inference #48656

Open
findleyr opened this issue Sep 27, 2021 · 4 comments
Open

go/types, types2: handle recursive constraint type inference #48656

findleyr opened this issue Sep 27, 2021 · 4 comments

Comments

@findleyr
Copy link
Contributor

@findleyr findleyr commented Sep 27, 2021

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
Copy link
Contributor

@griesemer griesemer commented Sep 27, 2021

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
Copy link

@gopherbot gopherbot commented Sep 28, 2021

Change https://golang.org/cl/352832 mentions this issue: cmd/compile/internal/types2: avoid infinite recursion in unification

gopherbot pushed a commit that referenced this issue Sep 28, 2021
If the type T inferred for a type parameter P is P itself (or a derived
type containing P), a subsequent unification step leads to infinite
recursion: at each encounter of P with the already inferred type T
(which is or contains P), P stands for that T and the recursive matching
process continues with T, which inevitably contains P again and recursion
never terminates.

This CL introduces a set of masks, one for each type parameter.
When a type parameter is encountered for which a type has already
been inferred, the type parameter is "masked" for the recursive
matching of the inferred type. Masking makes the type parameter
"invisible" such that it will be handled like any other type and
not unpacked further.

Fixes #48619.
For #48656.

Change-Id: Ic1d938322be51fd44323ea14f925303f58b27c97
Reviewed-on: https://go-review.googlesource.com/c/go/+/352832
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@gopherbot
Copy link

@gopherbot gopherbot commented Sep 29, 2021

Change https://golang.org/cl/353029 mentions this issue: go/types: avoid infinite recursion in unification

gopherbot pushed a commit that referenced this issue Sep 29, 2021
This is an almost clean port of CL 352832 from types2 to go/types:
The nest files and unify.go where copied verbatim; unify.go was
adjusted with correct package name, a slightly different comment
was restored to what it was. The test files got adjustments for
error position. infer.go got a missing _Todo error code.

For #48619.
For #48656.

Change-Id: Ia1a2d09e8bb37a85032b4b7e7c7a0b08e8c793a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353029
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@gopherbot
Copy link

@gopherbot gopherbot commented Oct 7, 2021

Change https://golang.org/cl/354690 mentions this issue: cmd/compile/internal/types2: fix unification (again)

gopherbot pushed a commit that referenced this issue Oct 8, 2021
…"fix"

The "fix" (CL 352832) for #48619 was incorrect and broke
the unification algorithm in some cases (e.g., #48695).

This CL reverts the changes made by CL 352832 to unify.go,
and comments out code in corresponding tests.

As a result, #48695 will be fixed, and we will re-open #48619.

Fixes #48695.
For #48619.
For #48656.

Change-Id: I91bc492062dbcc8dae7626f6b33f6dfabf48bcb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/354690
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants