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/cmd/gopls: inconsistent results from Completion #31822

Closed
myitcv opened this issue May 3, 2019 · 1 comment
Closed

x/tools/cmd/gopls: inconsistent results from Completion #31822

myitcv opened this issue May 3, 2019 · 1 comment

Comments

@myitcv
Copy link
Member

@myitcv myitcv commented May 3, 2019

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

$ go version
go version go1.12.4 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20190429181656-7af746645d51

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
GOARCH="amd64"
GOBIN="/home/myitcv/gostuff/src/github.com/myitcv/govim/cmd/govim/.bin"
GOCACHE="/home/myitcv/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPROXY=""
GORACE=""
GOROOT="/home/myitcv/gos"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
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-build107626790=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I'm seeing sporadic test failures in a govim test that verifies Completion is working.

https://github.com/myitcv/govim/blob/8d88770117b1bb42095e719ce25a4075f5350b6c/cmd/govim/testdata/complete.txt

The test attempts a completion in the position of the first argument to fmt.Println, and chooses the third candidate in the list.

The test failure implies that neither Const1 nor Const2 are being returned as completion candidates.

So whereas I would expected the candidate list to be:

fmt
Const1
Const2
main()
append(slice []T, elems ...T)
bool
byte
cap(v []T)
close(c chan<- T)
complex(real float64, imag float64)
complex128
complex64
copy(dst []T, src []T)
delete(m map[K]V, key K)
error
false
float32
float64
imag(complex128)
int
int16
int32
int64
int8
iota
len(T)
make(t T, size ...int)
new(T)
nil
panic(interface{})
print(args ...T)
println(args ...T)
real(complex128)
recover()
rune
string
true
uint
uint16
uint32
uint64
uint8
uintptr

it appears to be:

fmt
main()
append(slice []T, elems ...T)
bool
byte
cap(v []T)
close(c chan<- T)
complex(real float64, imag float64)
complex128
complex64
copy(dst []T, src []T)
delete(m map[K]V, key K)
error
false
float32
float64
imag(complex128)
int
int16
int32
int64
int8
iota
len(T)
make(t T, size ...int)
new(T)
nil
panic(interface{})
print(args ...T)
println(args ...T)
real(complex128)
recover()
rune
string
true
uint
uint16
uint32
uint64
uint8
uintptr

hence I see append completed and not Const2

This seems to suggest something racey going on, almost as if type checking has finished yet?

I think I would expect a completion request to block on a pending type check... but if my hunch about the reason for this being racey is wrong, that expectation will be equally wrong.


cc @stamblerre @ianthehat

@myitcv
Copy link
Member Author

@myitcv myitcv commented May 4, 2019

Actually this is my mistake. I misread the test failure I was getting. The test failure was actually in a test that verifies completion results post a file outside the editor being changed.

It's highly likely the test was being flakey because of a race between the handling of a the file watcher event and the completion request.

"Fixed" by adding a generous sleep:

https://github.com/myitcv/govim/blob/5762cfa543aa8f78b326195ace0a9bb4868d6b47/cmd/govim/testdata/complete_watched.txt#L9

@myitcv myitcv closed this May 4, 2019
@golang golang locked and limited conversation to collaborators May 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

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