@dominikh reports in slack that gopls' organizeImports is particularly slow when there is a method call on an undefined symbol, often when the symbol is short.
Coincidentally, I was just looking at this logic, and noticed that it would lead to a LOT of additional candidates for short unresolved references. For example a single selector on an undefined 'e' or 's' may require reading a large chunk of the module cache.
This should be straightforward to reproduce, if so, and probably not too hard to fix. Unfortunately, I suspect that the imprecise heuristic probably avoids some edge cases like gopkg.in paths, but even so we can handle those explicitly.
CC @adonovan @pjweinb
Comment From: gabyhelp
Similar Issues
- https://github.com/golang/go/issues/32750
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Comment From: gopherbot
Change https://go.dev/cl/591715 mentions this issue: internal/imports: optimize package name filtering