x/tools/gopls: don't apply completion budget to shallow completions

[cbelsole]

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

$ go version go1.15.1 darwin/amd64

Does this issue reproduce with the latest release?

Yes (0.5.0). Also tested in (0.4.4).

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/user/Library/Caches/go-build"
GOENV="/Users/user/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/user/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/user/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.15.1/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.15.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/user/projects/tools/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/xg/l6_pfk3x0_n5ltb8h3wd1k500000gn/T/go-build694027970=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

For large packages the completion was timing out. For example, typing fmt. produced no results. Using a local struct variable struct1. produced no results.

[Trace - 11:19:55.356 AM] Sending request 'textDocument/completion - (14)'.
Params: {"textDocument":{"uri":"file:///path/to/file.go"},"position":{"line":602,"character":5},"context":{"triggerKind":2,"triggerCharacter":"."}}
[Trace - 11:19:55.910 AM] Received response 'textDocument/completion - (14)' in 554ms.
Result: {"isIncomplete":false,"items":[]}

@heschik found the workaround. Adding:

"gopls": {
  "completionBudget": "0.5s"
}

to my vscode config gave the completion code more time to read the very large package. Now completion items are coming up.

There may be a bug here as:

@heschik: I'm not sure we want shallow completions to be subject to the budget, like Muir said

(slack convo)

What did you expect to see?

I expected to see the fmt public package methods and the methods attached to struct1.

What did you see instead?

No completions came up.

[heschi]

@stamblerre, is the behavior change you made in golang.org/cl/227303 still the one we want? If not this would be an easy fix for @dandua98.

[dandua98]

This might actually be fixed (in 0.5.1) now that deep completion is bfs and is triggered at the end of completions. I think this might be one of those scenarios with very large packages where we end up going too deep and not finding anything. Would need to be able to reproduce this and verify though.

[heschi]

It may have been improved, but I think it's still an open question whether we want to ever give up on searching the first level.

[stamblerre]

No, I think in that CL was a mistake on my part. If deep completions is more "isolated" now, it would be nice to only apply that timeout to deep completions, but to start the timer when the completion request starts. (I think I may have thought that that's what I was doing in that CL, but clearly I did it wrong...)

[gopherbot]

Change https://golang.org/cl/257974 mentions this issue: internal/lsp/source: run unimported completions after other deep completions.

[gopherbot]

Change https://golang.org/cl/258286 mentions this issue: internal/lsp/source: run deep completions before unimported completions

[cbelsole]

Some feedback on this change. In our largest package I still need to keep "completionBudget": "0.5s" in the config in order to get results back.

[gopherbot]

Change https://golang.org/cl/262347 mentions this issue: internal/lsp/source/completion: use a minimum budget of 10ms for shallow completions

[cbelsole]

Tested this in golang.org/x/tools/gopls v0.5.2 and I am now getting completions in our largest package without using "completionBudget": "0.5s".

[stamblerre]

Glad to hear it! I'll close this issue then.