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: panic when checking method on generic struct called from package-level function #57522
Comments
CC @griesemer Thanks for the detailed report! This looks like a type-checker bug. (gri: I'll take a look) |
Minimal reproducer:
The (invalid) selector causes evaluation of the method set of S before it is fully set up. |
I think the easiest fix is to avoid the lookup entirely in |
More reproducers / related panics:
Selectors and array lengths are two places where we evaluate expressions while checking type declarations, and therefore are vectors for this type of crasher. This needs a more systematic fix. Not sure if this can be done for 1.20, though perhaps we should land the selector fix. |
Change https://go.dev/cl/461577 mentions this issue: |
I think we can avoid most (but not all) instances of this type of crash with the CL above, which we should consider for 1.20. I have ideas for a more comprehensive fix for 1.21. |
As we have seen many times, the type checker must be careful to avoid accessing named type information before the type is fully set up. We need a more systematic solution to this problem, but for now avoid one case that causes a crash: checking a selector expression on an incomplete type when a type expression is expected. For #57522 Change-Id: I7ed31b859cca263276e3a0647d1f1b49670023a9 Reviewed-on: https://go-review.googlesource.com/c/go/+/461577 Run-TryBot: Robert Findley <rfindley@google.com> Auto-Submit: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
Moving this to 1.21 for the follow-up. |
@griesemer has been thinking about more general controls for lazy expansion; in the meantime this particular crash is fixed, so I will close this issue. |
gopls version
go env
What did you do?
Typing away in my editor (VSCode, though I don't think it matters), I made a couple of mistakes in a file containing some generics: trying to add a
[]string
formal parameter to a method, I typed[]STR
(because caps lock was on), and then made a second error in placing my cursor to start removing characters and ended up with a parameter type of[STR
. This causedgopls
to go into a tight crash loop.Whittling it down, I found this example produces a panic at the same location:
The names of things don't seem to matter, besides the match between the methodI thought this was the case, but I just tried withM
and packagefunc M
.func F() { V.M() }
and that also crashed.What did you expect to see?
Some sort of error like: "mismatched [" I suppose? I'm not really sure what
gopls check
looks like when it's working as intended.What did you see instead?
The immediate crash described above and below.
Editor and settings
I don't think it's relevant, since it's reproducible for me with a bare
gopls
invocation in an empty directory not part of any project, but I'm happy to provide these if it'd be helpful.Logs
The full stdio output from running the
gopls check ...
above that I see is:The text was updated successfully, but these errors were encountered: