x/tools/gopls: panic in fillstruct analyzer #39899
Closed
Milestone
Comments
Change https://golang.org/cl/240537 mentions this issue: |
Change https://golang.org/cl/240538 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Jun 30, 2020
The previous implementation missed a nil check which caused a panic when the package of a type was nil. Fixes: golang/go#39899 Change-Id: I2dfb50d6b79f52df367e093e5d857cd70b7cef27 Reviewed-on: https://go-review.googlesource.com/c/tools/+/240537 Run-TryBot: Josh Baum <joshbaum@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org> (cherry picked from commit aa3d501) Reviewed-on: https://go-review.googlesource.com/c/tools/+/240538 Run-TryBot: Rebecca Stambler <rstambler@golang.org> Reviewed-by: Josh Baum <joshbaum@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While experimenting with stress tests for gopls, I discovered that the new fillstruct analyzer causes a significant spike in CPU utilization: 5x more CPU in a test that just types randomly in github.com/pilosa/pilosa (a module for which gopls has historically had performance problems).Almost all of this type is formatting the modified AST (printer.Fprint) to generate suggested edits.I can provide more details if necessary, but it should be pretty easy to reproduce (just open pilosa and type). We probably should avoid computing this suggested fix on every keypress.Oops, it appears that the reason fillstruct was implicated was that it was panicking, and the way I had structured my stress test led to other results hitting the cache, whereas fillstruct missed the cache due to the panic below.
We've since produces more generalized mayhem by updating the stress test to type more randomly...
Updated this issue to instead refer to the fillstruct panic.
CC @joshbaum @stamblerre
The text was updated successfully, but these errors were encountered: