-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: internal compiler error importing a recursive type (recursive through a type constraint) #51219
Comments
To reproduce:
I think there's some confusion as to what Same as if you did:
Closing, as this is not a bug. Maybe there would be ways to improve the error messages (include definition line of the type name when it appears more than once in the error message?) but this is currently working as expected. |
Have you tried removing the assignment, though? Just to be clear, if you do remove the assignment you get a compiler internal error, which is for sure unexpected It's also where an issue comes in, JsonRaw isn't defined as a type & a variable, it's used as a type in the Type Parameter on the receiver, but nowhere is it defined by something else. I'm not sure why the type parameter on the receiver would turn out to be its own new type identifier when it shouldn't be? It makes it literally impossible to make specific implementations of methods on structures with type parameters? |
I should have been more clear earlier, my mistake; I tried diving into the problem but it ended up like an X/Y problem To reproduce the error building & the error message git clone https://github.com/Karitham/corde
cd corde
git checkout ae8ae03a3401df2f1a6a365e81742bf90acfaf94
go test ./... Full stack trace
|
This relates to importing a complex recursive type. This issue only happens if the recursion happens through the type constraint. (In this program, the recursion actually goes through two different type constraints!) I have the rough fix (small changes to the importers), but creating a minimized test case may take a while. I believe this is not a release-blocker, because of the unusual situation of recursion through the type constraint. |
Change https://go.dev/cl/386335 mentions this issue: |
I went to port this fix to x/tools/go/internal/gcimporter, and observed that it doesn't reproduce with the x/tools importer/exporter. @danscales mentioned something similar, that the error was not locally reproducible with the types2 importer. This suggests that there's some inconsistency across the types/import/export APIs. Reopening because we should nail down the root cause. |
Change https://go.dev/cl/387814 mentions this issue: |
The existing test for 51219 didn't actually trigger the types2 issue - I hadn't been able to minimize the test case yet properly. This new test case issue51219b.go now does trigger the types2 issue (it's only slightly different). Updates #51219 Change-Id: Iaba8144b4702ff4fefec86c899b8acef127b10dc Reviewed-on: https://go-review.googlesource.com/c/go/+/387814 Trust: Dan Scales <[email protected]> Reviewed-by: Robert Findley <[email protected]>
Change https://go.dev/cl/392475 mentions this issue: |
Change https://go.dev/cl/392634 mentions this issue: |
For golang/go#51219 Change-Id: I62982e0ea084f78e81ec5ea6d6a0b6a039941968 Reviewed-on: https://go-review.googlesource.com/c/tools/+/392634 Trust: Robert Findley <[email protected]> Run-TryBot: Robert Findley <[email protected]> gopls-CI: kokoro <[email protected]> Reviewed-by: Suzy Mueller <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Change https://go.dev/cl/392734 mentions this issue: |
type parameters This is a partial port of CL 386335 to x/tools. I have not yet been able to reproduce the crash in a test. For golang/go#51219 Change-Id: I262e6a9dba936b18513ee5f11a2a72d4155d3833 Reviewed-on: https://go-review.googlesource.com/c/tools/+/392475 Trust: Robert Findley <[email protected]> Run-TryBot: Robert Findley <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]> gopls-CI: kokoro <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Change https://go.dev/cl/392915 mentions this issue: |
For golang/go#51219 Change-Id: Ib60fc1f22ce9ff094bc87ec36ad9e2c07c422c6e Reviewed-on: https://go-review.googlesource.com/c/tools/+/392915 Trust: Robert Findley <[email protected]> Run-TryBot: Robert Findley <[email protected]> gopls-CI: kokoro <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Hyang-Ah Hana Kim <[email protected]>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
1.18beta1, beta2 & gotip
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Using type parameters, I get a compiler panic in an assignment.
I have tried extremely hard to provide a better program, but haven't managed to reproduce the bug easily on the playground.
See https://github.com/Karitham/corde/blob/error/compiler-panic/components/interactions.go#L148-L156 for the whole codebase with the log
What did you expect to see?
Either a compile error that makes sense, or my program building (most likely the second one, but I'm not familiar enough with generics yet to expect my code to be 100% valid)
What did you see instead?
Nonsensical error message and/or compiler panic
The text was updated successfully, but these errors were encountered: