x/tools/gopls: providing incomplete completions

[sbromberger]

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

go version go1.13.4 linux/amd64

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=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/g/g17/seth/.cache/go-build"
GOENV="/g/g17/seth/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/g/g17/seth/dev/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/g/g17/seth/.local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/g/g17/seth/.local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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=/var/tmp/seth/go-build901721020=/tmp/go-build -gno-record-gcc-switches"

What did you do?

vim version

VIM - Vi IMproved 8.1 (2018 May 18, compiled Nov  6 2019 09:15:14)
Included patches: 1-2264

With govim, the minimal vimrc, and gopls master installed, attempted to complete an mpi command following the mpi.Start() line:

package main

import (
        "fmt"

        mpi "github.com/sbromberger/gompi"
)

func main() {
      fmt.Println("foo")
      mpi.Start()
}

I typed in mpi. and then hit ^x^o to perform a govim autocomplete. The only results returned were Byte.String, Complex.String, and Double.String.

What did you expect to see?

Other options including mpi.Stop

What did you see instead?

See above.

Log files attached.

Also note: problem manifests using ALE as well.

gopls_log_20191106_1300_53_965670529.txt

govim_log_20191106_1300_53_952147754.txt

vim_channel_log_20191106_1300_53_hIB6mB1hoOFX.txt

[gopherbot]

Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here.

[gopherbot]

Change https://golang.org/cl/205737 mentions this issue: internal/lsp: debugging CL for golang/go#35406

[stamblerre]

Thanks for filing this! Just uploaded CL 205737, which you can patch into your gopls installation to add some more verbose logging. If you could install it and upload new logs, that would be very helpful.

To install: cd into your golang.org/x/tools directory, sync to master, and then select "Download Patch" from the "..." menu in the top right corner. Copy the "Cherry Pick" command and then execute it in the tools directory. Rebuild gopls (cd gopls && go install && cd ..), and then you should be running with the CL.

[sbromberger]

Here are the logs with the cherry-picked patch:

vim_channel_log_20191106_1828_25_XQv6GAXO981I.txt

gopls_log_20191106_1828_25_888116519.txt

govim_log_20191106_1828_25_963720936.txt

[sbromberger]

after 2nd cherry-pick:

vim_channel_log_20191106_2210_20_PaPigolJ5CBj.txt

gopls_log_20191106_2210_20_422053540.txt

govim_log_20191106_2210_20_667118105.txt

[stamblerre]

Oh, I think I understand what's happening with the logs - govim pins a gopls version to use, so it looks like it's using the pinned version and not the rebuilt one (in the logs, the build info references a version of x/tools from 11/04/2019, which would've been set here (govim/govim@07d2b75). @myitcv can probably shed some light here - how can @sbromberger go about testing with a different version of gopls?

[muirdm]

Expanding on my theory from slack, I think this might just be a cgo problem. If you can build the cgo package, then files that use cgo aren't part of the package because they are replaced by generated files (so they don't work for completion or code navigation). If you can't build the package (because you are missing the C headers), then the preprocessing fails and the source files are type checked directly, so things work for the most part.

@sbromberger you should be able to test this theory by changing something to break the cgo build for that package (e.g. remove the mpi.h header). Restart gopls and then try completing again.

[sbromberger]

It is a cgo problem, but it's a strange one. That is, the presence of this environment variable:

CGO_LDFLAGS_ALLOW=.*

causes the incomplete behavior. When I unset it, things work.

This is likely due to the fact that that var is required for the package to work, and lends further support to @muirdm's theory.

[sbromberger]

That said: is there a workaround for this? My code is simply a wrapper around the C; it's designed to expose the equivalent Go functions. An example:

func Start() {
        C.MPI_Init(nil, nil)
}

and

func (o Communicator) RecvByte(fromID, tag int) byte {
        var v byte
        buf := unsafe.Pointer(&v)
        C.MPI_Recv(buf, 1, dataTypes[Byte], C.int(fromID), C.int(tag), o.comm, C
.StIgnore)
        return v
}

Could it be as simple as checking to see if the file is cgo-related, and if so, type check against the source directly?

[muirdm]

Unfortunately cgo is not really supported yet in gopls. See #32898 (this issue can probably be closed as a dupe). There is a workaround patch in #32898 (comment).

[muirdm]

After some more consideration, it seems like this should work fine. I think the problem is the completion fails because it can't find the documentation for the cgo package's members. This probably has to do with the generated cgo file swaperoo. Anyway, an easy workaround is to disable documentation by setting the gopls config flag "completionDocumentation" to false.

[gopherbot]

Change https://golang.org/cl/205862 mentions this issue: internal/lsp: return completion item without documentation