Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
myitcv opened this issue Jan 21, 2020 · 9 comments
Closed

Comments

@myitcv
Copy link
Member

@myitcv myitcv commented Jan 21, 2020

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 0cba7a3a 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 0cba7a3a.

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

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jan 21, 2020

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

@myitcv

This comment has been minimized.

Copy link
Member Author

@myitcv myitcv commented Jan 26, 2020

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 8fe064f8.

The test fails in exactly the same way described above.

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

@myitcv myitcv reopened this Jan 26, 2020
@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Jan 26, 2020

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

This comment has been minimized.

Copy link
Member Author

@myitcv myitcv commented Jan 26, 2020

Here you go: gopls.log

@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Jan 26, 2020

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

This comment has been minimized.

@stamblerre stamblerre changed the title x/tools/gopls: unimported completions do not work when file does not exist on disk x/tools/gopls: scenario_completeunimported/complete_new_file (govim) test flaky Jan 28, 2020
@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Jan 28, 2020

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

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jan 28, 2020

Change https://golang.org/cl/216637 mentions this issue: internal/lsp: recover from a view initialization failure

@myitcv

This comment has been minimized.

Copy link
Member Author

@myitcv myitcv commented Jan 28, 2020

Thanks - the changes in that CL (and other CLs) do appear to fix this issue. I'll leave this open and let the submitting of that CL close this.

myitcv pushed a commit to myitcvforks/tools that referenced this issue Jan 28, 2020
If an orphaned file is used to recover a workspace package, we should
remove the initialization error and treat the view as correctly
initialized.

Also, stop caching metadata for packages with no files. We have no way
to invalidate it, and it's useless, so just re-load those files as
needed.

Fixes golang/go#36795.
Fixes golang/go#36671.
Fixes golang/go#36772.

Change-Id: I0aee5a43401517b6073d27136cca533160effef2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.