-
Notifications
You must be signed in to change notification settings - Fork 18k
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/internal/gcimporter: untyped interface type parameter causes "panic: nil underlying" during testing #57015
Comments
I can't reproduce this locally, either with current tip or with c85848a |
I haven't been able to reproduce this either. Can you still reproduce this, @csgura? |
Sorry for the late reply. |
I can reproduce. This is |
@randall77 what exactly did you do to reproduce? I copied the files exactly (I thought), and don't see the same at tip. Without |
Nevermind, I copied from the wrong playground link. I can reproduce. |
go.mod:
main.go:
option.go:
option_test.go:
|
Thanks, I am able to reproduce. Will take a closer look later this afternoon. The error suggests that we're trying to instantiate with a type that isn't completely set up. This is related to the new ureader code, but may be an artifact of overly tricky setup for importing named types via go/types. CC @mdempsky |
Does this need to block the RC? |
Ok, I looked into it. This panic can be reached via importing the following package:
The issue is that in the unified importer, Playing around with the unified importer, I see that we can make this work by invoking |
I don't think so. It affects vet, so at most it would affect testing setups. You could still build a binary and test it in production without fixing this issue. Although if your test doesn't compile, you may not want to push an untested binary to production... |
@heschi @randall77 I'm not sure what the threshold is for the RC, but this seems like it would be pretty easy encounter when using the RC. |
Assigning to @mdempsky since this is related to the unified importer and https://go.dev/cl/424876 looks like a candidate fix. Matthew: can we revisit that CL? |
Change https://go.dev/cl/424876 mentions this issue: |
Change https://go.dev/cl/456376 mentions this issue: |
This is a port of CL 424876, except it temporarily maintains a fallback path for older cmd/compile behavior before CL 455279, to avoid breaking users following Go tip. Updates golang/go#57015. Change-Id: I168d171153d96485e92be19645422fe65ab4b345 Reviewed-on: https://go-review.googlesource.com/c/tools/+/456376 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Matthew Dempsky <mdempsky@google.com> gopls-CI: kokoro <noreply+kokoro@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
https://go.dev/play/p/ZQZ-dOAbTbo?v=gotip
What did you expect to see?
No Error
What did you see instead?
The text was updated successfully, but these errors were encountered: