go: x/tools/cmd/gopls: fails on certain projects

go version go1.12.4 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/john/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/john/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.4/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.4/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/q3/ybqqxyh92yd0yc865zqk0vpm0000gn/T/go-build749386462=/tmp/go-build -gno-record-gcc-switches -fno-common"

VS Code 1.33.1 51b0b28134d51361cf996d2f0a1c698247aeabd8 x64
vscode-go 0.10.1

gopls settings as here: https://github.com/golang/go/wiki/gopls

Steps to reproduce:

Create a main.go file in a new directory.
Enter this code:

package main

func main() {
	os.Exit(1)
}

Save

An automatic import "os" is added. I can hover the mouse over os.Exit and see pop-up information about the function. If I delete the Exit(1), place the cursor after os. and hit Ctrl-Space, I see an auto-complete menu showing the available functions in os.

Add a go.mod file with go mod init tmp.
Delete the import "os" line and save the file again. Now the auto import is no longer added, the hover doc does not appear, and there is no auto-complete menu.

(Transferred from https://github.com/Microsoft/vscode-go/issues/2476)

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 1
Comments: 53 (18 by maintainers)

Commits related to this issue

internal/lsp: fix swallowed package errors If a package has an error that makes it completely unparsable, such as containing a .go file with no "package" statement, the error was previously unreporte... — committed to evandigby/tools by evandigby 5 years ago
internal/lsp: fix swallowed package errors If a package has an error that makes it completely unparsable, such as containing a .go file with no "package" statement, the error was previously unreporte... — committed to evandigby/tools by evandigby 5 years ago
internal/lsp: fix swallowed package errors If a package has an error that makes it completely unparsable, such as containing a .go file with no "package" statement, the error was previously unreporte... — committed to evandigby/tools by evandigby 5 years ago

Most upvoted comments

It does not crash now, but the problem does not seem to be solved. I still have errors like this:

[Error - 19:04:28] Request textDocument/codeAction failed.
  Message: no room in queue
  Code: -32000 
[Error - 19:04:29] Request textDocument/codeAction failed.
  Message: no room in queue
  Code: -32000 
[Error - 19:04:29] Request textDocument/hover failed.
  Message: no room in queue
  Code: -32000

universonic on May 18, 2019

You will also need to configure this VSCode setting if you don’t already have it:

"go.toolsEnvVars": {
    "GO111MODULE": "on"
}

stamblerre on Apr 27, 2019

We are, however, working on changing this, as tracked in https://github.com/golang/go/issues/32587.

stamblerre on Jun 13, 2019

@marco-m the TL;DR of that issue was ‘without a go.mod file, gopls can do nothing’.

bitfield on Jun 13, 2019

@marco-m: The follow-up to this was in https://github.com/golang/go/issues/32142, which was ultimately closed as working as intended. If you are experiencing a problem with gopls, please file a separate issue with information about your environment and logs. Even though these issues can look similar to one another, they can often be traced back to different underlying causes.

stamblerre on Jun 12, 2019

Do you mind filing new issues with your individual errors? This issue has been quite long and has had multiple problems reported in it, so it’s difficult to follow. Let’s start individual new issues for each specific error seen.

stamblerre on May 20, 2019

gopls has no persistence of any kind, if you restart it it starts from scratch every time. It stores nothing on disk and in it’s default mode aquires no os resources that could collide with a separate gopls process (like sockets). In its default form, it communicates exclusively with its host process on stdin/stdout and only looks at the local file system. The only external command it relies on is the go command itself, and it only uses that for go list to discover files and packages.

ianthehat on May 16, 2019

Two points about that:

Are you saying it’s a design feature of gopls that it doesn’t provide any editor support for files with build tags? I wonder if it might not be possible to rethink this. From the point of view of someone who’s editing Go code, they would naturally expect to be able to get autocompletion, auto imports, and so on, regardless of any build tags on the file. I think you can expect a lot of issues opened against gopls by people who don’t understand this decision and, when informed of it, will ask for it to be reversed.
The same problems are evident in another file in the same project which is not excluded by build tags. So that issue is not a duplicate, as far as I know.

bitfield on May 2, 2019