x/tools/gopls: scenario_completeunimported/complete_new_file (govim) test flaky

[myitcv]

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

$ go version
go version devel +8e0be05ec7 Sun Jan 19 14:04:09 2020 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20200117220505-0cba7a3a9ee9 => github.com/myitcvforks/tools v0.0.0-20200119092928-0fd5434cd1ba
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.1.8-0.20200117220505-0cba7a3a9ee9 => github.com/myitcvforks/tools/gopls v0.0.0-20200119092928-0fd5434cd1ba

Note that per govim/govim@c7a6cc3, github.com/myitcvforks/tools/gopls@v0.0.0-20200119092928-0fd5434cd1ba is 0cba7a3 with a partial revert of CL214586 on top (the result of which can be seen in https://go-review.googlesource.com/c/tools/+/215239)

The issue described below also exists when tested against 0cba7a3.

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=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
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"
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-build573600991=/tmp/go-build -gno-record-gcc-switches"

What did you do?

As part of govim/govim#699 we are adding some tests that verify gopls behaviour with files that are not saved on disk.

One of these tests is for unimported completions.

The sequence is:

• create a new buffer (which does not exist on disk)
• populate buffer with the following contents:

package main

func main() {

}

Attempt a completion on line 4 with fmt.Pr

What did you expect to see?

Expected candidates to include fmt.Println

What did you see instead?

No completion candidates.

gopls log file: gopls.log

---

cc @stamblerre @muirdm @heschik

FYI @leitzler

[gopherbot]

Change https://golang.org/cl/215681 mentions this issue: internal/imports: pass dummy source for completion functions

[myitcv]

Re-opening because we're seeing some flakey behaviour here. About 20% of the time in govim tests we're not getting any completion results (could be related to #36661 (comment)?).

We are seeing these failures again 8fe064f.

The test fails in exactly the same way described above.

The gopls log file for a failing run: gopls.log

[stamblerre]

Similarly, as on #36661, would it be possible to generate a log with verboseOutput turned on? It looks like a go list failure (my guess is a context cancellation that isn't being handled correctly).

[myitcv]

Here you go: gopls.log

[stamblerre]

This also looks like another case where we're failing to load the package correctly - it's being loaded ad-hoc, which is why you see the "command-line-arguments" package path. Is there a go.mod file for this test, or is the intention that nothing at all is on disk?

[myitcv]

Yes, this is a go.mod in this instance:

https://github.com/govim/govim/blob/013f992e25f23cbc4a778d1eb472e719d276de32/cmd/govim/testdata/scenario_completeunimported/complete_new_file.txt#L25-L28

[stamblerre]

I am not able to reproduce this test failure locally with https://golang.org/cl/216637.