go/types, types2: panic: infinite recursion in unification with go1.21.0 #61879
Comments
LAShZ
added
gopls
|
after downgrade to gopls this panic still occured, maybe go1.21.0 is the cause |
|
After tying
I have confirmed that go1.21.0 should be blamed for this panic |
findleyr
changed the title
|
CC @griesemer Can you share anything about the code being edited? Is this an open-source project? Does compilation succeed? |
findleyr
added
the
NeedsInvestigation
Sorry, but this is not an open-source project yet and the project is quite large, so I can not share code that can reproduce this panic (Actually, I have not edit anything, only upgrade go && gopls). However, I have tried on several projects we are working on and panic occurs every time. (But in some small code snippets, I write for fun, gopls and go function normally)
In fact, our project depends on some pkg that can only be built between go1.16~go1.20, so I cannot confirm if the project can be built with go 1.21.0. However, with go 1.20.6, compilation was successful as expected. |
If the package can't be built by go1.21, that is a bug in go1.21? Perhaps it is the same bug as you report here? The compiler's type checker and gopls's type checker are kept in sync, so I would expect them both to have the same unification problem. It would be extremely helpful if we could narrow down a reproducer. Could you try compiling different packages to see which fail? I can also create a CL in the Go repo that would print more information in this panic, but that would require that you re-build Go. |
|
The reason why the package I mentioned can not be built by go1.21 is because it uses some JIT tricks and has build tags like
It would be ok if you want me to use some customized go version to get more information. |
|
Change https://go.dev/cl/518259 mentions this issue: |
|
https://go.dev/cl/518259 forget to add debug code to |
|
@ttys3 gopls doesn't depend on types2; that's only used for the compiler. @LAShZ can you try with this CL? The easiest way to install go with that CL is to use go install golang.org/dl/gotip@latest
gotip download 518259
gotip install golang.org/x/tools/gopls@latestThen the unification panic should contain more detail, that can help us narrow down a reproducer. |
This comment was marked as outdated.
This comment was marked as outdated.
|
@LAShZ that is not the new panic message. Perhaps the gopls used by your editor is still the old version. Can you check |
This comment was marked as duplicate.
This comment was marked as duplicate.
|
|
|
Aha, that's not the correct gopls. Can you ensure your editor uses the version in /Users/lavch/sdk/gotip/bin (perhaps by modifying PATH, or by copying that gopls somewhere)? |
|
I got you, after using the new go version, the And I will paste the full |
|
Thanks. Those server logs still appear to be using the old version. Are you sure your editor is finding the right one? You may also be able to reproduce the panic by simply running |
|
With the output
Sadly, I only got the output like this: So the problem might be caused by some package I depend on. |
|
I have located the package that caused the panic. Let me try to provide a reproducer. |
|
@findleyr Here is the reproducer type InterfaceA[T comparable] interface {
setData(string) InterfaceA[T]
}
type ImplA[T comparable] struct {
data string
args []any
}
func NewInterfaceA[T comparable](args ...any) InterfaceA[T] {
return &ImplA[T]{
data: fmt.Sprintf("%v", args...),
args: args,
}
}
func (k *ImplA[T]) setData(data string) InterfaceA[T] {
k.data = data
return k
}
func Foo[M ~map[InterfaceA[T]]V, T comparable, V any](m M) {
// DO SOMETHING HERE
return
}
func Bar() {
keys := make([]InterfaceA[int], 0, 10)
m := make(map[InterfaceA[int]]int)
for i := 0; i < 10; i++ {
keys = append(keys, NewInterfaceA[int](i))
m[keys[i]] = i
}
Foo(m) // panic here
}And I've noticed that although |
|
@LAShZ amazing! That also reproduces via playground compilation: Huge thanks. Tracking down a reproducer is critical to fixing the compiler. |
findleyr
changed the title
|
@griesemer and I will try to fix this for Go1.21.1. @gopherbot please backport this to 1.21. It is a new panic during type checking. |
|
Backport issue(s) opened: #61959 (for 1.21). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
@findleyr yes. gopls doesn't depend on types2. we got an ICE. while using go 1.21 compile our program. but I think it maybe the same to the gopls issue. I patched src/cmd/compile/internal/types2/unify.go and confirmed that, it's an ICE |
|
Simpler reproducer: package p
type Interface[T any] interface {
m(Interface[T])
}
func f[S []Interface[T], T any](S) {}
func _() {
var s []Interface[int]
f(s) // panic here
} |
|
Inference trace: Inference should recognize that we're comparing the very same interface, once instantiated and once uninstantiated, and immediately infer the type parameter from the given type argument. |
|
Change https://go.dev/cl/519435 mentions this issue: |
|
Change https://go.dev/cl/519455 mentions this issue: |
dmitshur
added
NeedsFix
Irrespective of whether unification is exact or inexact, method signatures of interfaces must always match exactly: a type never satisfies/implements an interface if relevant method signatures are different (i.e., not identical, possibly after substitution). This change matches the fix https://go.dev/cl/519435. For #61879. Change-Id: I28b0a32d32626d85afd32e107efce141235a923d Reviewed-on: https://go-review.googlesource.com/c/go/+/519455 TryBot-Bypass: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com>
gopls version
go env
What did you do?
Updagrade go version to 1.21.0，and upgrade gopls to v0.13.1
What did you expect to see?
gopls function normally
What did you see instead?
gopls panic
Editor and settings
VSCode
Logs
The text was updated successfully, but these errors were encountered: