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: providing incomplete completions #35406

Closed
sbromberger opened this issue Nov 6, 2019 · 12 comments
Closed

x/tools/gopls: providing incomplete completions #35406

sbromberger opened this issue Nov 6, 2019 · 12 comments
Assignees
Labels
Milestone

Comments

@sbromberger
Copy link

@sbromberger sbromberger commented Nov 6, 2019

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 gopherbot added this to the Unreleased milestone Nov 6, 2019
@gopherbot gopherbot added the Tools label Nov 6, 2019
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Nov 6, 2019

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 gopherbot added the gopls label Nov 6, 2019
@stamblerre stamblerre changed the title x/tools/gopls providing incomplete completions x/tools/gopls: providing incomplete completions Nov 6, 2019
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Nov 6, 2019

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

@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Nov 6, 2019

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.

@stamblerre stamblerre self-assigned this Nov 7, 2019
@sbromberger

This comment has been minimized.

@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Nov 7, 2019

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

This comment has been minimized.

Copy link

@muirdm muirdm commented Nov 7, 2019

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

This comment has been minimized.

Copy link
Author

@sbromberger sbromberger commented Nov 7, 2019

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

This comment has been minimized.

Copy link
Author

@sbromberger sbromberger commented Nov 7, 2019

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

This comment has been minimized.

Copy link

@muirdm muirdm commented Nov 7, 2019

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

@sbromberger sbromberger closed this Nov 7, 2019
@muirdm

This comment has been minimized.

Copy link

@muirdm muirdm commented Nov 7, 2019

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.

@sbromberger sbromberger reopened this Nov 7, 2019
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Nov 7, 2019

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

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
4 participants
You can’t perform that action at this time.