What version of Go are you using (go version)?

$ go version
go version devel go1.17-b7a85e0003 Fri Jul 30 14:01:30 2021 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.1.5-0.20210708231608-69948257bde7
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.0.0-20210708231608-69948257bde7

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/myitcv/gostuff/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel go1.17-b7a85e0003 Fri Jul 30 14:01:30 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/govim/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3105452222=/tmp/go-build -gno-record-gcc-switches"

What did you do?

The setup is as follows:

-- go.mod --
module playground.com

go 1.16

require cuelang.org/go v0.4.0
-- main.go --
package main

func main() {
}

I then open main.go, edit as follows:

package main

func main() {
        load.Inst
}

and attempt unimported completion at the end of the line load.Inst, which should resolve to cuelang.org/go/cue/load.Instances.

My observations:

  • When 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 that cuelang.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?)
  • It also appears that the results of the module cache scan are not themselves cached when using a remote gopls instance. At least that appears to be what I'm seeing, because if I close a govim instances (which is using remote gopls) 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 closing govim, 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 when gopls 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.
  • In my experiments locally, I often see random results when request unimported completions. I'm not clear whether this is happening during the scan of the module cache, or after, or something else, but I attach a log file below.

bad.log

Notes:

  • This was starting a remote instance from cold
  • The first three requests come back with zero results, despite cuelang.org/go being a module requirement
  • Then we start to get "duplicates" from different versions of the cuelang.org/go module:
cuelang.org/go/beta.1/cue/load
cuelang.org/go/cue/load
cuelang.org/go/beta.2/cue/load
cuelang.org/go/rc.1.0.20210521174241-37bf801bb051/cue/load
...
  • I then made further requests, and the results that come back are somewhat arbitrary. I can't really tell if there is pattern, or whether/when things get "fixed"

What did you expect to see?

As noted above:

  • Consistent and correct unimported completion results without
  • Cached results of the module cache scan when using a remote gopls
  • Faster results on a cold start where the results are from a module dependency

What did you see instead?

As above

cc @stamblerre

FYI @leitzler

Comment From: pjweinb

This may be fixed in the next gopls release.