x/tools/gopls: unimported completion delay, random results and caches not persisted with remote? #47615
Labels
gopls
Issues related to the Go language server, gopls.
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Tools
This label describes issues relating to any tools in the x/tools repository.
Milestone
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?
The setup is as follows:
I then open
main.go
, edit as follows:and attempt unimported completion at the end of the line
load.Inst
, which should resolve tocuelang.org/go/cue/load.Instances
.My observations:
gopls
starts from cold (i.e. first remote instance, or no remote at all), the first few unimported completion requests come back with zero results. Whilst this is somewhat to be expected, I would have hoped that the module requirements could be prioritised and processed very quickly, such thatcuelang.org/go/cue/load.Instances
could be determined as a candidate almost immediately, at which point a more time consuming scan of the module cache could start. Furthermore, this scan of existing module requirements could be triggered when the workspace is established, rather than waiting for the first unimported completion request (which I what I think is happening?)gopls
instance. At least that appears to be what I'm seeing, because if I close agovim
instances (which is using remotegopls
) and then open the same file again, I again get empty unimported completion results until (presumably) the module cache has been walked again. Contrast not closinggovim
, deleting an import and then re-requesting unimported completions, the results are instantaneous (because the cache is warm). Furthermore, it would be ideal if the module cache scan was triggered whengopls
first loads (in remote mode?) to avoid the first few requests being empty as far as possible, but this is really nitpicking: caching the results would already be a huge win.bad.log
Notes:
cuelang.org/go
being a module requirementcuelang.org/go
module:What did you expect to see?
As noted above:
gopls
What did you see instead?
As above
cc @stamblerre
FYI @leitzler
The text was updated successfully, but these errors were encountered: