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.

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

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.

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

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

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?

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.

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.

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?

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).

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.

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