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: fails on certain projects #31712

Closed
bitfield opened this issue Apr 27, 2019 · 53 comments
Closed

x/tools/cmd/gopls: fails on certain projects #31712

bitfield opened this issue Apr 27, 2019 · 53 comments

Comments

@bitfield
Copy link

@bitfield bitfield commented Apr 27, 2019

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:

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

func main() {
	os.Exit(1)
}
  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.

  1. Add a go.mod file with go mod init tmp.

  2. 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 microsoft/vscode-go#2476)

@gopherbot gopherbot added the gopls label Apr 27, 2019
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Apr 27, 2019

Can you try reloading the VSCode window after you create the module?

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Apr 27, 2019

Also, how was it working before? Is the directory in your $GOPATH?

@stamblerre stamblerre changed the title gopls: stops working if go.mod present x/tools/cmd/gopls: run go/packages.Load when go.mod created Apr 27, 2019
@gopherbot gopherbot added this to the Unreleased milestone Apr 27, 2019
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Apr 27, 2019

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

"go.toolsEnvVars": {
    "GO111MODULE": "on"
}
@bitfield
Copy link
Author

@bitfield bitfield commented Apr 28, 2019

  1. Reloading the window or restarting VS Code makes no difference.
  2. The directory is not in GOPATH.
  3. Setting go.ToolsEnvVars makes no difference.

Interestingly, though, gopls is working in another project which has a go.mod. So although starting a new project as described reliably reproduces the issue, I can't pin it down to just having a go.mod.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Apr 29, 2019

If the directory is not in your $GOPATH, gopls will not work until you have added a go.mod file, so I'm not sure I understand your repro case. It sounds to me like your configurations are not entirely correct. What is the output of go list -e -json -compiled -test in this directory?

Additionally, you will require the go.toolsEnvVars configuration to be set as I specified above, but note that it is with a lowercase t, not uppercase.

@bitfield
Copy link
Author

@bitfield bitfield commented Apr 30, 2019

Well, my repro instructions no longer reproduce the problem, which is encouraging! However, I still have several projects where gopls is not responding at all. Here's the go list output from one:

{
	"Dir": "/Users/john/git/paidy/terraform-aws-ecs-deployment/test",
	"ImportPath": "test-service",
	"Name": "main",
	"Target": "/Users/john/go/bin/test-service",
	"Module": {
		"Path": "test-service",
		"Main": true,
		"Dir": "/Users/john/git/paidy/terraform-aws-ecs-deployment/test",
		"GoMod": "/Users/john/git/paidy/terraform-aws-ecs-deployment/test/go.mod",
		"GoVersion": "1.12"
	},
	"Match": [
		"."
	],
	"IgnoredGoFiles": [
		"integration_test.go"
	],
	"Deps": [
		"internal/bytealg",
		"internal/cpu",
		"runtime",
		"runtime/internal/atomic",
		"runtime/internal/math",
		"runtime/internal/sys",
		"unsafe"
	],
	"TestGoFiles": [
		"unit_test.go"
	],
	"TestImports": [
		"github.com/gruntwork-io/terratest/modules/terraform",
		"testing"
	]
}
{
	"Dir": "/Users/john/git/paidy/terraform-aws-ecs-deployment/test",
	"ImportPath": "test-service.test",
	"Name": "main",
	"Stale": true,
	"StaleReason": "stale dependency: github.com/gruntwork-io/terratest/modules/terraform",
	"GoFiles": [
		"/Users/john/Library/Caches/go-build/b5/b5b2ca548dd492c9c0e6a582646698053c7d8333d0c52a33a78b48c1aefb957f-d"
	],
	"CompiledGoFiles": [
		"/Users/john/Library/Caches/go-build/b5/b5b2ca548dd492c9c0e6a582646698053c7d8333d0c52a33a78b48c1aefb957f-d"
	],
	"Imports": [
		"os",
		"test-service [test-service.test]",
		"testing",
		"testing/internal/testdeps"
	],
	"ImportMap": {
		"test-service": "test-service [test-service.test]"
	},
	"Deps": [
		"bufio",
		"bytes",
		"compress/flate",
		"compress/gzip",
		"context",
		"crypto",
		"crypto/aes",
		"crypto/cipher",
		"crypto/des",
		"crypto/dsa",
		"crypto/ecdsa",
		"crypto/elliptic",
		"crypto/hmac",
		"crypto/internal/randutil",
		"crypto/internal/subtle",
		"crypto/md5",
		"crypto/rand",
		"crypto/rc4",
		"crypto/rsa",
		"crypto/sha1",
		"crypto/sha256",
		"crypto/sha512",
		"crypto/subtle",
		"crypto/x509",
		"crypto/x509/pkix",
		"encoding",
		"encoding/asn1",
		"encoding/base64",
		"encoding/binary",
		"encoding/hex",
		"encoding/json",
		"encoding/pem",
		"errors",
		"flag",
		"fmt",
		"github.com/gruntwork-io/terratest/modules/collections",
		"github.com/gruntwork-io/terratest/modules/customerrors",
		"github.com/gruntwork-io/terratest/modules/files",
		"github.com/gruntwork-io/terratest/modules/logger",
		"github.com/gruntwork-io/terratest/modules/retry",
		"github.com/gruntwork-io/terratest/modules/shell",
		"github.com/gruntwork-io/terratest/modules/ssh",
		"github.com/gruntwork-io/terratest/modules/terraform",
		"golang.org/x/crypto/curve25519",
		"golang.org/x/crypto/ed25519",
		"golang.org/x/crypto/ed25519/internal/edwards25519",
		"golang.org/x/crypto/internal/chacha20",
		"golang.org/x/crypto/internal/subtle",
		"golang.org/x/crypto/poly1305",
		"golang.org/x/crypto/ssh",
		"golang.org/x/crypto/ssh/agent",
		"golang.org/x/net/context",
		"hash",
		"hash/crc32",
		"internal/bytealg",
		"internal/cpu",
		"internal/fmtsort",
		"internal/nettrace",
		"internal/poll",
		"internal/race",
		"internal/singleflight",
		"internal/syscall/unix",
		"internal/testlog",
		"internal/x/crypto/cryptobyte",
		"internal/x/crypto/cryptobyte/asn1",
		"internal/x/net/dns/dnsmessage",
		"internal/x/net/route",
		"io",
		"io/ioutil",
		"log",
		"math",
		"math/big",
		"math/bits",
		"math/rand",
		"net",
		"net/url",
		"os",
		"os/exec",
		"path/filepath",
		"reflect",
		"regexp",
		"regexp/syntax",
		"runtime",
		"runtime/cgo",
		"runtime/debug",
		"runtime/internal/atomic",
		"runtime/internal/math",
		"runtime/internal/sys",
		"runtime/pprof",
		"runtime/trace",
		"sort",
		"strconv",
		"strings",
		"sync",
		"sync/atomic",
		"syscall",
		"test-service [test-service.test]",
		"testing",
		"testing/internal/testdeps",
		"text/tabwriter",
		"time",
		"unicode",
		"unicode/utf16",
		"unicode/utf8",
		"unsafe"
	]
}
{
	"Dir": "/Users/john/git/paidy/terraform-aws-ecs-deployment/test",
	"ImportPath": "test-service [test-service.test]",
	"Name": "main",
	"ForTest": "test-service",
	"Module": {
		"Path": "test-service",
		"Main": true,
		"Dir": "/Users/john/git/paidy/terraform-aws-ecs-deployment/test",
		"GoMod": "/Users/john/git/paidy/terraform-aws-ecs-deployment/test/go.mod",
		"GoVersion": "1.12"
	},
	"Match": [
		"."
	],
	"Stale": true,
	"StaleReason": "stale dependency: github.com/gruntwork-io/terratest/modules/terraform",
	"GoFiles": [
		"unit_test.go"
	],
	"CompiledGoFiles": [
		"unit_test.go"
	],
	"IgnoredGoFiles": [
		"integration_test.go"
	],
	"Imports": [
		"github.com/gruntwork-io/terratest/modules/terraform",
		"testing"
	],
	"Deps": [
		"bufio",
		"bytes",
		"context",
		"crypto",
		"crypto/aes",
		"crypto/cipher",
		"crypto/des",
		"crypto/dsa",
		"crypto/ecdsa",
		"crypto/elliptic",
		"crypto/hmac",
		"crypto/internal/randutil",
		"crypto/internal/subtle",
		"crypto/md5",
		"crypto/rand",
		"crypto/rc4",
		"crypto/rsa",
		"crypto/sha1",
		"crypto/sha256",
		"crypto/sha512",
		"crypto/subtle",
		"crypto/x509",
		"crypto/x509/pkix",
		"encoding",
		"encoding/asn1",
		"encoding/base64",
		"encoding/binary",
		"encoding/hex",
		"encoding/json",
		"encoding/pem",
		"errors",
		"flag",
		"fmt",
		"github.com/gruntwork-io/terratest/modules/collections",
		"github.com/gruntwork-io/terratest/modules/customerrors",
		"github.com/gruntwork-io/terratest/modules/files",
		"github.com/gruntwork-io/terratest/modules/logger",
		"github.com/gruntwork-io/terratest/modules/retry",
		"github.com/gruntwork-io/terratest/modules/shell",
		"github.com/gruntwork-io/terratest/modules/ssh",
		"github.com/gruntwork-io/terratest/modules/terraform",
		"golang.org/x/crypto/curve25519",
		"golang.org/x/crypto/ed25519",
		"golang.org/x/crypto/ed25519/internal/edwards25519",
		"golang.org/x/crypto/internal/chacha20",
		"golang.org/x/crypto/internal/subtle",
		"golang.org/x/crypto/poly1305",
		"golang.org/x/crypto/ssh",
		"golang.org/x/crypto/ssh/agent",
		"golang.org/x/net/context",
		"hash",
		"internal/bytealg",
		"internal/cpu",
		"internal/fmtsort",
		"internal/nettrace",
		"internal/poll",
		"internal/race",
		"internal/singleflight",
		"internal/syscall/unix",
		"internal/testlog",
		"internal/x/crypto/cryptobyte",
		"internal/x/crypto/cryptobyte/asn1",
		"internal/x/net/dns/dnsmessage",
		"internal/x/net/route",
		"io",
		"io/ioutil",
		"log",
		"math",
		"math/big",
		"math/bits",
		"math/rand",
		"net",
		"net/url",
		"os",
		"os/exec",
		"path/filepath",
		"reflect",
		"regexp",
		"regexp/syntax",
		"runtime",
		"runtime/cgo",
		"runtime/debug",
		"runtime/internal/atomic",
		"runtime/internal/math",
		"runtime/internal/sys",
		"runtime/trace",
		"sort",
		"strconv",
		"strings",
		"sync",
		"sync/atomic",
		"syscall",
		"testing",
		"time",
		"unicode",
		"unicode/utf16",
		"unicode/utf8",
		"unsafe"
	],
	"TestGoFiles": [
		"unit_test.go"
	],
	"TestImports": [
		"github.com/gruntwork-io/terratest/modules/terraform",
		"testing"
	]
}

you will require the go.toolsEnvVars configuration to be set as I specified above, but note that it is with a lowercase t, not uppercase

That was my mistake in the comment; the configuration is correct.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Apr 30, 2019

Ok, for one of the packages that is not working for you, do you mind attaching the log output for gopls? To get it, you can go to "View: Debug Console" -> "Output" -> "Tasks" drop-down -> "gopls".

@wiredprairie
Copy link

@wiredprairie wiredprairie commented Apr 30, 2019

I've been seeing similar issues to @bitfield where in some projects (or files?) the VS Code IDE seems to be fine and others not. I've not found any consistent ways to cause the issue. I even removed the GOPATH environment variable entirely, which I thought helped -- but doesn't consistently either.

I cleared the Debug Console output for gopls and this was the only thing that displayed when I saved the active file (I'd intentionally poorly formatted the file to see if formatting would work again--it did not).

[Error - 12:18:22 PM] Request textDocument/formatting failed.
  Message: ToUTF16Column: point is missing offset
  Code: 0 

There aren't any other errors.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Apr 30, 2019

@wiredprairie: Are you on Windows? There seem to be some issues with formatting there (see #31150, which I'm currently investigating). Can you try another feature, like completion?

@wiredprairie
Copy link

@wiredprairie wiredprairie commented Apr 30, 2019

@stamblerre - yes, Windows 10 (1809). Code completion seems to work consistently. Auto import does not. Are there other features you'd like me to try?

I just looked at the linked issue; the formatting may be more than just a LF issue -- I've had it work and not work, with the same projects on Windows (and only edited on Windows).

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Apr 30, 2019

Thanks for letting me know. I will continue investigating formatting. For imports, do you have this setting configured?

"[go]": {
    "editor.formatOnSave": true,
    "editor.codeActionsOnSave": {
        "source.organizeImports": true
    },
},
@wiredprairie
Copy link

@wiredprairie wiredprairie commented Apr 30, 2019

I verified the settings exist (and restarted VS Code). No change.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Apr 30, 2019

Hm, @wiredprairie, it looks like you are definitely running into #31150, which is strange because formatting should work perfectly fine on Windows (I checked yesterday). Would you be able to share your logs? (They can be found by going to "View: Debug Console" -> "Output" -> "Tasks" and selection "gopls" from the dropdown.)

@wiredprairie
Copy link

@wiredprairie wiredprairie commented Apr 30, 2019

Sure @stamblerre

  1. Rebooted PC
  2. Started VS Code (v 1.33.1)
  3. Made a simple formatting only change to some existing code
cacheAndDiagnose: file:///c:/Users/Demo/Dev/renamed-app/server/client.go
cacheAndDiagnose: set content for file:///c:/Users/Demo/Dev/renamed-app/server/client.go
cacheAndDiagnose: returned from diagnostics for file:///c:/Users/Demo/Dev/renamed-app/server/client.go
cacheAndDiagnose: going to get diagnostics for file:///c:/Users/Demo/Dev/renamed-app/server/client.go
running `go vet` analyses for file:///c:/Users/Demo/Dev/renamed-app/server/client.go
analyses have completed for github.com/wiredprairie/game_shots_server
completed reporting `go vet` analyses for file:///c:/Users/Demo/Dev/renamed-app/server/client.go
cacheAndDiagnose: publishing diagnostics
cacheAndDiagnose: publishing undelivered diagnostics
[Error - 6:36:34 PM] Request textDocument/codeAction failed.
  Message: ToUTF16Column: point is missing offset
  Code: 0 
@bitfield
Copy link
Author

@bitfield bitfield commented May 1, 2019

Ok, for one of the packages that is not working for you, do you mind attaching the log output for gopls?

Here we go:

[Error - 9:47:34 AM] Request textDocument/codeAction failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
didChange: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: set content for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: returned from diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: going to get diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
found parse or type-checking errors for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go, returning
cacheAndDiagnose: publishing diagnostics
cacheAndDiagnose: publishing undelivered diagnostics
didChange: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: set content for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: returned from diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: going to get diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
found parse or type-checking errors for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go, returning
cacheAndDiagnose: publishing diagnostics
cacheAndDiagnose: publishing undelivered diagnostics
[Error - 9:47:35 AM] Request textDocument/completion failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
didChange: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: set content for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: returned from diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: going to get diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
[Error - 9:47:35 AM] Request textDocument/completion failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
found parse or type-checking errors for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go, returning
cacheAndDiagnose: publishing diagnostics
cacheAndDiagnose: publishing undelivered diagnostics
didChange: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: set content for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: returned from diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: going to get diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
found parse or type-checking errors for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go, returning
cacheAndDiagnose: publishing diagnostics
cacheAndDiagnose: publishing undelivered diagnostics
[Error - 9:47:36 AM] Request textDocument/completion failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
didChange: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: set content for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: returned from diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: going to get diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
[Error - 9:47:36 AM] Request textDocument/completion failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
found parse or type-checking errors for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go, returning
cacheAndDiagnose: publishing diagnostics
cacheAndDiagnose: publishing undelivered diagnostics
didChange: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: set content for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: returned from diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: going to get diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
found parse or type-checking errors for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go, returning
cacheAndDiagnose: publishing diagnostics
cacheAndDiagnose: publishing undelivered diagnostics
[Error - 9:47:37 AM] Request textDocument/completion failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
[Error - 9:47:37 AM] Request textDocument/codeAction failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
didChange: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: set content for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: returned from diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: going to get diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
[Error - 9:47:37 AM] Request textDocument/signatureHelp failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
found parse or type-checking errors for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go, returning
cacheAndDiagnose: publishing diagnostics
cacheAndDiagnose: publishing undelivered diagnostics
[Error - 9:47:37 AM] Request textDocument/codeAction failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
didChange: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: set content for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: returned from diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: going to get diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
[Error - 9:47:37 AM] Request textDocument/signatureHelp failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
found parse or type-checking errors for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go, returning
cacheAndDiagnose: publishing diagnostics
cacheAndDiagnose: publishing undelivered diagnostics
[Error - 9:47:37 AM] Request textDocument/codeAction failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
[Error - 9:47:37 AM] Request textDocument/codeAction failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
[Error - 9:47:37 AM] Request textDocument/formatting failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
didChange: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: set content for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: returned from diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
cacheAndDiagnose: going to get diagnostics for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
found parse or type-checking errors for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go, returning
cacheAndDiagnose: publishing diagnostics
cacheAndDiagnose: publishing undelivered diagnostics
[Error - 9:47:40 AM] Request textDocument/codeAction failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 1, 2019

Do you happen to have any build constraints in your package? Can I see the output of go list -e -json -compiled -test for this package? It seems the one from earlier is for a different directory.

The errors you are seeing basically indicate that gopls can't build your package. Do you see diagnostics for this file?

@bitfield
Copy link
Author

@bitfield bitfield commented May 1, 2019

{
	"Dir": "/Users/john/git/thirtythree/infra/modules/azure_vm/test",
	"ImportPath": "test",
	"Name": "main",
	"Target": "/Users/john/go/bin/test",
	"Module": {
		"Path": "test",
		"Main": true,
		"Dir": "/Users/john/git/thirtythree/infra/modules/azure_vm/test",
		"GoMod": "/Users/john/git/thirtythree/infra/modules/azure_vm/test/go.mod",
		"GoVersion": "1.12"
	},
	"Match": [
		"."
	],
	"IgnoredGoFiles": [
		"integration_test.go"
	],
	"Deps": [
		"internal/bytealg",
		"internal/cpu",
		"runtime",
		"runtime/internal/atomic",
		"runtime/internal/math",
		"runtime/internal/sys",
		"unsafe"
	],
	"TestGoFiles": [
		"unit_test.go"
	],
	"TestImports": [
		"github.com/gruntwork-io/terratest/modules/terraform",
		"os",
		"testing"
	]
}
{
	"Dir": "/Users/john/git/thirtythree/infra/modules/azure_vm/test",
	"ImportPath": "test.test",
	"Name": "main",
	"Stale": true,
	"StaleReason": "stale dependency: test",
	"GoFiles": [
		"/Users/john/Library/Caches/go-build/45/450f5e561bd765b077f025fd60ca15d61cd2f4261f8230c8d14f80f2c31bda9c-d"
	],
	"CompiledGoFiles": [
		"/Users/john/Library/Caches/go-build/45/450f5e561bd765b077f025fd60ca15d61cd2f4261f8230c8d14f80f2c31bda9c-d"
	],
	"Imports": [
		"os",
		"test [test.test]",
		"testing",
		"testing/internal/testdeps"
	],
	"ImportMap": {
		"test": "test [test.test]"
	},
	"Deps": [
		"bufio",
		"bytes",
		"compress/flate",
		"compress/gzip",
		"context",
		"crypto",
		"crypto/aes",
		"crypto/cipher",
		"crypto/des",
		"crypto/dsa",
		"crypto/ecdsa",
		"crypto/elliptic",
		"crypto/hmac",
		"crypto/internal/randutil",
		"crypto/internal/subtle",
		"crypto/md5",
		"crypto/rand",
		"crypto/rc4",
		"crypto/rsa",
		"crypto/sha1",
		"crypto/sha256",
		"crypto/sha512",
		"crypto/subtle",
		"crypto/x509",
		"crypto/x509/pkix",
		"encoding",
		"encoding/asn1",
		"encoding/base64",
		"encoding/binary",
		"encoding/hex",
		"encoding/json",
		"encoding/pem",
		"errors",
		"flag",
		"fmt",
		"github.com/gruntwork-io/terratest/modules/collections",
		"github.com/gruntwork-io/terratest/modules/customerrors",
		"github.com/gruntwork-io/terratest/modules/files",
		"github.com/gruntwork-io/terratest/modules/logger",
		"github.com/gruntwork-io/terratest/modules/retry",
		"github.com/gruntwork-io/terratest/modules/shell",
		"github.com/gruntwork-io/terratest/modules/ssh",
		"github.com/gruntwork-io/terratest/modules/terraform",
		"golang.org/x/crypto/curve25519",
		"golang.org/x/crypto/ed25519",
		"golang.org/x/crypto/ed25519/internal/edwards25519",
		"golang.org/x/crypto/internal/chacha20",
		"golang.org/x/crypto/internal/subtle",
		"golang.org/x/crypto/poly1305",
		"golang.org/x/crypto/ssh",
		"golang.org/x/crypto/ssh/agent",
		"golang.org/x/net/context",
		"hash",
		"hash/crc32",
		"internal/bytealg",
		"internal/cpu",
		"internal/fmtsort",
		"internal/nettrace",
		"internal/poll",
		"internal/race",
		"internal/singleflight",
		"internal/syscall/unix",
		"internal/testlog",
		"internal/x/crypto/cryptobyte",
		"internal/x/crypto/cryptobyte/asn1",
		"internal/x/net/dns/dnsmessage",
		"internal/x/net/route",
		"io",
		"io/ioutil",
		"log",
		"math",
		"math/big",
		"math/bits",
		"math/rand",
		"net",
		"net/url",
		"os",
		"os/exec",
		"path/filepath",
		"reflect",
		"regexp",
		"regexp/syntax",
		"runtime",
		"runtime/cgo",
		"runtime/debug",
		"runtime/internal/atomic",
		"runtime/internal/math",
		"runtime/internal/sys",
		"runtime/pprof",
		"runtime/trace",
		"sort",
		"strconv",
		"strings",
		"sync",
		"sync/atomic",
		"syscall",
		"test [test.test]",
		"testing",
		"testing/internal/testdeps",
		"text/tabwriter",
		"time",
		"unicode",
		"unicode/utf16",
		"unicode/utf8",
		"unsafe"
	]
}
{
	"Dir": "/Users/john/git/thirtythree/infra/modules/azure_vm/test",
	"ImportPath": "test [test.test]",
	"Name": "main",
	"ForTest": "test",
	"Module": {
		"Path": "test",
		"Main": true,
		"Dir": "/Users/john/git/thirtythree/infra/modules/azure_vm/test",
		"GoMod": "/Users/john/git/thirtythree/infra/modules/azure_vm/test/go.mod",
		"GoVersion": "1.12"
	},
	"Match": [
		"."
	],
	"Stale": true,
	"StaleReason": "not installed but available in build cache",
	"GoFiles": [
		"unit_test.go"
	],
	"CompiledGoFiles": [
		"unit_test.go"
	],
	"IgnoredGoFiles": [
		"integration_test.go"
	],
	"Imports": [
		"github.com/gruntwork-io/terratest/modules/terraform",
		"os",
		"testing"
	],
	"Deps": [
		"bufio",
		"bytes",
		"context",
		"crypto",
		"crypto/aes",
		"crypto/cipher",
		"crypto/des",
		"crypto/dsa",
		"crypto/ecdsa",
		"crypto/elliptic",
		"crypto/hmac",
		"crypto/internal/randutil",
		"crypto/internal/subtle",
		"crypto/md5",
		"crypto/rand",
		"crypto/rc4",
		"crypto/rsa",
		"crypto/sha1",
		"crypto/sha256",
		"crypto/sha512",
		"crypto/subtle",
		"crypto/x509",
		"crypto/x509/pkix",
		"encoding",
		"encoding/asn1",
		"encoding/base64",
		"encoding/binary",
		"encoding/hex",
		"encoding/json",
		"encoding/pem",
		"errors",
		"flag",
		"fmt",
		"github.com/gruntwork-io/terratest/modules/collections",
		"github.com/gruntwork-io/terratest/modules/customerrors",
		"github.com/gruntwork-io/terratest/modules/files",
		"github.com/gruntwork-io/terratest/modules/logger",
		"github.com/gruntwork-io/terratest/modules/retry",
		"github.com/gruntwork-io/terratest/modules/shell",
		"github.com/gruntwork-io/terratest/modules/ssh",
		"github.com/gruntwork-io/terratest/modules/terraform",
		"golang.org/x/crypto/curve25519",
		"golang.org/x/crypto/ed25519",
		"golang.org/x/crypto/ed25519/internal/edwards25519",
		"golang.org/x/crypto/internal/chacha20",
		"golang.org/x/crypto/internal/subtle",
		"golang.org/x/crypto/poly1305",
		"golang.org/x/crypto/ssh",
		"golang.org/x/crypto/ssh/agent",
		"golang.org/x/net/context",
		"hash",
		"internal/bytealg",
		"internal/cpu",
		"internal/fmtsort",
		"internal/nettrace",
		"internal/poll",
		"internal/race",
		"internal/singleflight",
		"internal/syscall/unix",
		"internal/testlog",
		"internal/x/crypto/cryptobyte",
		"internal/x/crypto/cryptobyte/asn1",
		"internal/x/net/dns/dnsmessage",
		"internal/x/net/route",
		"io",
		"io/ioutil",
		"log",
		"math",
		"math/big",
		"math/bits",
		"math/rand",
		"net",
		"net/url",
		"os",
		"os/exec",
		"path/filepath",
		"reflect",
		"regexp",
		"regexp/syntax",
		"runtime",
		"runtime/cgo",
		"runtime/debug",
		"runtime/internal/atomic",
		"runtime/internal/math",
		"runtime/internal/sys",
		"runtime/trace",
		"sort",
		"strconv",
		"strings",
		"sync",
		"sync/atomic",
		"syscall",
		"testing",
		"time",
		"unicode",
		"unicode/utf16",
		"unicode/utf8",
		"unsafe"
	],
	"TestGoFiles": [
		"unit_test.go"
	],
	"TestImports": [
		"github.com/gruntwork-io/terratest/modules/terraform",
		"os",
		"testing"
	]
}

When you say:

Do you see diagnostics for this file?

Which file specifically? The only diagnostics I see in the Output tab are the same as earlier:

[Error - 6:55:18 PM] Request textDocument/codeAction failed.
  Message: no file information for file:///Users/john/git/thirtythree/infra/modules/azure_vm/test/integration_test.go
  Code: 0 

It certainly builds, and tests pass!

@ianthehat
Copy link

@ianthehat ianthehat commented May 1, 2019

I looks like you are trying to do something with azure_vm/test/integration_test.go which is in the set of "IgnoredGoFiles", presumably because it is excluded by a build tag.
I am going to close this as a duplicate of #31668, please feel free to re-open if you think this is not the case.

@ianthehat ianthehat closed this May 1, 2019
@bitfield
Copy link
Author

@bitfield bitfield commented May 2, 2019

Two points about that:

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

  2. 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
Copy link
Author

@bitfield bitfield commented May 3, 2019

(By the way, I can't re-open the issue, but I'd appreciate it if you would.)

@dominikh dominikh reopened this May 4, 2019
@bitfield
Copy link
Author

@bitfield bitfield commented May 7, 2019

Is there any progress on this? I watched someone install VS Code and the Go extension from scratch the other day, and there was no auto-formatting, no auto-completion, no hover docs, and no auto-imports for them either. It's not much fun having to keep explaining that the good people at Google are working on it, but it's still early days!

On the other point, should I open an issue requesting gopls support for files with build tags? (see #31712 (comment))

@ianthehat
Copy link

@ianthehat ianthehat commented May 7, 2019

Build tags is not a decision so much as a fundamental limitation. Almost all of the features that gopls offers require type checking, which requires a valid set of build tags.
The issue is already being tracked in #29202
If the same issue is present in a non build tagged file, I need the logs for that (or a reproduction that I can follow). At the moment I cannot reproduce the issue, and there are no other reports of it, so I cannot do anything to help without more information.

@bitfield
Copy link
Author

@bitfield bitfield commented May 8, 2019

Thanks for your persistence! I'm having some trouble reliably reproducing this at the moment; I noticed yesterday that when I was working on a project, gopls started out working fine, became slower and slower, and finally stopped working altogether. Reloading the window, closing and re-opening the window, quitting and restarting VS Code, and re-installing gopls didn't fix the issue. I saw no logs in the 'Output' window; where should I look to find information that will help you diagnose the problem?

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 8, 2019

The Output window will have a dropdown titled "Tasks" - gopls should be one of the list and that will contain the logs.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 13, 2019

I don't think that gcc would be related, but @bitfiled, what version of gopls are you using? Have you updated lately?

@bitfield
Copy link
Author

@bitfield bitfield commented May 13, 2019

I'm not sure, how can I find out?

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 13, 2019

You can update by running go get -u golang.org/x/tools/cmd/gopls. You can check by running git log in the x/tools directory. gopls is a pretty active project so things change quite frequently.

@bitfield
Copy link
Author

@bitfield bitfield commented May 13, 2019

Updated... and the new version has a gopls version command, which the previous one didn't!

    golang.org/x/tools@v0.0.0-20190511041617-99f201b6807e h1:wTxRxdzKt8fn3IQa3+kVlPJMxK2hJj2Orm+M2Mzw9eg=
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 13, 2019

Ok, great thank you. I will try to add some additional logging for the "no file information" error case, and if you encounter these errors again, please update this issue with additional logs.

@evandigby
Copy link

@evandigby evandigby commented May 16, 2019

Update to earlier. The problem has returned so the other two things (as you probably already suspected) were likely not the culprits.

One thing that is consistent between the two times it happened is is that I was working in VSCode then closed my laptop's lid which is set to put it to sleep. It then hibernates after a while.

When I reopen the laptop the language server isn't working (I haven't yet had the foresight to look at the output for gopls) so I restart VSCode. After it restarts I get the issue.

Is there some form of cache that could be getting corrupted?

@ianthehat
Copy link

@ianthehat ianthehat commented May 16, 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.

@evandigby
Copy link

@evandigby evandigby commented May 16, 2019

This line masks an error:
https://github.com/golang/tools/blob/master/internal/lsp/cache/file.go#L87-L96

func (f *goFile) GetToken(ctx context.Context) *token.File {
	f.view.mu.Lock()
	defer f.view.mu.Unlock()
	if f.token == nil || len(f.view.contentChanges) > 0 {
		if _, err := f.view.parse(ctx, f); err != nil {
			return nil
		}
	}
	return f.token
}

If I throw a panic in there I get the following:

func (f *goFile) GetToken(ctx context.Context) *token.File {
	f.view.mu.Lock()
	defer f.view.mu.Unlock()
	if f.token == nil || len(f.view.contentChanges) > 0 {
		if _, err := f.view.parse(ctx, f); err != nil {
			panic(err)
			return nil
		}
	}
	return f.token
}
panic: package github.com/evandigby/kafka/api/records has errors, skipping type-checking

goroutine 6 [running]:
golang.org/x/tools/internal/lsp/cache.(*goFile).GetToken(0xc00026ed80, 0x904a60, 0xc0001f93c0, 0x0)
	/home/evdigby/code/tools/internal/lsp/cache/file.go:92 +0x136
golang.org/x/tools/internal/lsp.getSourceFile(0x904a60, 0xc0001f93c0, 0x909e60, 0xc00020a240, 0xc0002843c0, 0x41, 0xc00020a240, 0x81b3a0, 0xc0002725a0, 0x0, ...)
	/home/evdigby/code/tools/internal/lsp/util.go:54 +0xcb
golang.org/x/tools/internal/lsp.(*Server).codeAction(0xc00014a5a0, 0x904a60, 0xc0001f93c0, 0xc0002684e0, 0xc0002684e0, 0x0, 0x0, 0x0, 0xc00025c210)
	/home/evdigby/code/tools/internal/lsp/code_action.go:20 +0xfa
golang.org/x/tools/internal/lsp.(*Server).CodeAction(0xc00014a5a0, 0x904a60, 0xc0001f93c0, 0xc0002684e0, 0xc0002684e0, 0x0, 0x0, 0x0, 0x0)
	/home/evdigby/code/tools/internal/lsp/server.go:203 +0x4d
golang.org/x/tools/internal/lsp/protocol.serverHandler.func1(0x904a60, 0xc0001f93c0, 0xc0001540e0, 0xc00024bd20)
	/home/evdigby/code/tools/internal/lsp/protocol/tsserver.go:366 +0x2e4e
golang.org/x/tools/internal/jsonrpc2.(*Conn).Run.func1(0xc000072ae0, 0xc0001540e0)
	/home/evdigby/code/tools/internal/jsonrpc2/jsonrpc2.go:276 +0xda
created by golang.org/x/tools/internal/jsonrpc2.(*Conn).Run
	/home/evdigby/code/tools/internal/jsonrpc2/jsonrpc2.go:270 +0xbd

I suspect this is expected behavior masked behind a return nil where we should be returning the actual error.

I'm going to dig further for my own interest, but this says to me there's something wrong enough with the package that it just can't do anything right now.

Would it be possible / advisable to run other things like formatting, imports, etc. even without the specifics that it can't run? This specific file (afaik) has no such errors. It seems like if there's a package level problem it just can't do anything.

@evandigby
Copy link

@evandigby evandigby commented May 16, 2019

If this is a bug I'd like to tackle it if you think the scope is small enough for a first contribution. I can work on it over the next few days.

If it is bigger than you'd like to give to a first time contributor since, given the interfaces, I could see how it'd be difficult to cleanly handle this error, I'm happy to defer to someone with more experience in this code-base :)

@evandigby
Copy link

@evandigby evandigby commented May 16, 2019

Sorry for the barrage of comments.

Updated my "panic" to report the specific package errors:

func (f *goFile) GetToken(ctx context.Context) *token.File {
	f.view.mu.Lock()
	defer f.view.mu.Unlock()
	if f.token == nil || len(f.view.contentChanges) > 0 {
		if pkgErrs, err := f.view.parse(ctx, f); err != nil {
			errString := ""
			for _, e := range pkgErrs {
				errString += fmt.Sprintf("%v\n", e.Error())
			}
			panic(errString)
			return nil
		}
	}
	return f.token
}

With that I got the following

panic: -: 
api/records/attributes.go:13:1: expected 'package', found 'type'

This is correct, and expected. It was me being silly and having a legitimate package-level issue (missing package ... in a file).

Having said that, there is so much rich information that (IMO) should be bubbled up here. That's exactly the type of issue I would hope gopls would be reporting to me in this case.

Update (to clarify): There's no error reported on the file that's actually causing this issue. I definitely see why it would be okay to not "bubble" the issue up when it comes to that file; however, the file in question is completely grey'd out with no error:

state

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 16, 2019

Thank you for the detailed report! Totally agree that we need to do a better job of propagating those errors. The issue here is in the way that we compute diagnostics to show the user.

We basically try to match a file to its package, and then we send diagnostics for all of the errors in that package. Since you were missing a package ... statement, we weren't able to match the file to it's package.

Was the file in question opened in your editor? If yes, I would've expected it to reach this code on internal/lsp/source/diagnostics.go:64:

pkg := gof.GetPackage(ctx)
if pkg == nil {
	return singleDiagnostic(uri, "%s is not part of a package", uri), nil
}

This would then show a diagnostic to the user. If it was not open, I'm afraid there's not much we could do. If you haven't opened a file, we are not aware of it or its contents yet, and if you think it is in package, but it's actually not, it ends up orphaned. The best we could do is perhaps preemptively check all of the files in the package's directory.

@evandigby
Copy link

@evandigby evandigby commented May 16, 2019

The file in question is the one currently inside the editor. It hits the same error. It seems that error is somehow short circuiting other tests/logic. I’ll dig into why and follow up!

@evandigby
Copy link

@evandigby evandigby commented May 16, 2019

There are a few issues going on here:

  • reporting diagnostics requires pkg.GetFilenames() to return values, which it doesn't in the case of this error:

    	// Prepare the reports we will send for this package.
    	reports := make(map[span.URI][]Diagnostic)
    	for _, filename := range pkg.GetFilenames() {
    		reports[span.FileURI(filename)] = []Diagnostic{}
    	}
  • reporting diagnostics requires getSourceFile to work as it's required to get the range:

     func toProtocolDiagnostics(ctx context.Context, v source.View, diagnostics []source.Diagnostic) 
     ([]protocol.Diagnostic, error) {
      reports := []protocol.Diagnostic{}
      for _, diag := range diagnostics {
      	_, m, err := getSourceFile(ctx, v, diag.Span.URI())
      	if err != nil {
      		return nil, err
      	}
      	var severity protocol.DiagnosticSeverity
      	switch diag.Severity {
      	case source.SeverityError:
      		severity = protocol.SeverityError
      	case source.SeverityWarning:
      		severity = protocol.SeverityWarning
      	}
      	rng, err := m.Range(diag.Span)
      	if err != nil {
      		return nil, err
      	}
      	reports = append(reports, protocol.Diagnostic{
      		Message:  diag.Message,
      		Range:    rng,
      		Severity: severity,
      		Source:   diag.Source,
      	})
      }
      return reports, nil
     }
    • When that's updated to try to get the range another way, I realized that go list doesn't return a position for the actual error that's happening. It would be possible to parse the position from the error message but I'm not sure that's going to be reliable.
    {
      "Dir": "/home/evdigby/personal/kafka/api/records",
      "ImportPath": "github.com/evandigby/kafka/api/records",
      "Name": "records",
      "Match": [
      	"."
      ],
      "Incomplete": true,
      "Stale": true,
      "StaleReason": "build ID mismatch",
      "GoFiles": [
      	"batch.go",
      	"control_record.go",
      	"message_set.go",
      	"record.go"
      ],
      "Error": {
      	"ImportStack": [
      		"github.com/evandigby/kafka/api/records"
      	],
      	"Pos": "",
      	"Err": "\nattributes.go:13:1: expected 'package', found 'type'"
      }
    }

Solution possibilities

First the diagnostic function needs to be fixed to not ignore the files that are being encountered in package errors.

After that there are a few paths forward:

  1. Attempt to parse the position from the go list error.
  2. If possible, report a "package level" diagnostic with no specific file position.
  3. "Fix" the output from go list (out of scope of gopls I imagine).

1 may be difficult to make robust; however, 2 is easier than 1 if and only if it's possible to report a package level diagnostic. 3 is ideal but that requires understanding of why it doesn't return a pos for this error in the first place.

I'm going to play with solutions for my own interest. If I land on one that works I'll submit the PR if only to elicit some discussion.

evandigby added a commit to evandigby/tools that referenced this issue May 16, 2019
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 unreported. Such errors would manifest as other errors.

Fixes golang/go#31712
@gopherbot
Copy link

@gopherbot gopherbot commented May 16, 2019

Change https://golang.org/cl/177605 mentions this issue: internal/lsp: fix swallowed package errors

evandigby added a commit to evandigby/tools that referenced this issue May 16, 2019
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 unreported. Such errors would manifest as other errors.

Fixes golang/go#31712
evandigby added a commit to evandigby/tools that referenced this issue May 17, 2019
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 unreported. Such errors would manifest as other errors.

Fixes golang/go#31712
@bitfield
Copy link
Author

@bitfield bitfield commented May 18, 2019

Pardon me, but this doesn't necessarily fix the issue. (It may fix some issues.)

@universonic
Copy link

@universonic universonic commented May 18, 2019

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
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 20, 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.

@marco-m
Copy link

@marco-m marco-m commented Jun 12, 2019

@bitfield I was following this thread like watching a thriller on TV until I found it closed and your comment that

Pardon me, but this doesn't necessarily fix the issue. (It may fix some issues.)

If you opened a separate issue as suggested, could you please post it here so poor souls like me with your same problem can follow? :-) And thanks for opening the ticket!

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Jun 12, 2019

@marco-m: The follow-up to this was in #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.

@bitfield
Copy link
Author

@bitfield bitfield commented Jun 13, 2019

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

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Jun 13, 2019

We are, however, working on changing this, as tracked in #32587.

@golang golang locked and limited conversation to collaborators Jun 12, 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.

10 participants
You can’t perform that action at this time.