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

Jump to bottom

x/tools/gopls: excessive packages.Load calls with an ad-hoc package outside of GOPATH/module #42813

Closed
RomanKornev opened this issue Nov 24, 2020 · 9 comments
Closed

x/tools/gopls: excessive packages.Load calls with an ad-hoc package outside of GOPATH/module #42813

RomanKornev opened this issue Nov 24, 2020 · 9 comments
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
vscode-go: gopls by default
Milestone
gopls/v0.5.5

Comments

@RomanKornev
Copy link

What version of Go, VS Code & VS Code Go extension are you using?

  • Run go version to get version of Go
    • go version go1.15.2 darwin/amd64
  • Run gopls -v version to get version of Gopls if you are using the language server.
    • golang.org/x/tools/gopls v0.5.3
      golang.org/x/tools/gopls@v0.5.3 h1:C8QSrqjqaVzlVoHL1R9yWbROoOApRgI8gN1G+cHlPuw=
      github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
      github.com/google/go-cmp@v0.5.1 h1:JFrFEBb2xKufg6XkJsJr+WbKb4FQlURi5RUcBveYu9k=
      github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
      golang.org/x/mod@v0.3.0 h1:RM4zey1++hCTbCVQfnWeKs9/IEsaBLA8vTkd0WVtmH4=
      golang.org/x/sync@v0.0.0-20201020160332-67f06af15bc9 h1:SQFwaSi55rU7vdNs9Yr0Z324VNlrF+0wMqRXT4St8ck=
      golang.org/x/tools@v0.0.0-20201110032815-ae45d7cf37a9 h1:S0ATUNSw92bO7f5Z+1tSQsq48TdQs2Ye2rTGJdtf5qc=
      golang.org/x/xerrors@v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
      honnef.co/go/tools@v0.0.1-2020.1.6 h1:W18jzjh8mfPez+AwGLxmOImucz/IFjpNlrKVnaj2YVc=
      mvdan.cc/gofumpt@v0.0.0-20200927160801-5bfeb2e70dd6 h1:z+/YqapuV7VZPvBb3GYmuEJbA88M3PFUxaHilHYVCpQ=
      mvdan.cc/xurls/v2@v2.2.0 h1:NSZPykBXJFCetGZykLAxaL6SIpvbVy/UFEniIfHAa8A=
  • Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders
    • 1.51.1
  • Check your installed extensions to get the version of the VS Code Go extension
    • 0.18.1
  • Run go env to get the go development environment details
    • GO111MODULE=""
      GOARCH="amd64"
      GOBIN=""
      GOCACHE="/Users/df/Library/Caches/go-build"
      GOENV="/Users/df/Library/Application Support/go/env"
      GOEXE=""
      GOFLAGS=""
      GOHOSTARCH="amd64"
      GOHOSTOS="darwin"
      GOINSECURE=""
      GOMODCACHE="/Users/df/go/pkg/mod"
      GONOPROXY=""
      GONOSUMDB=""
      GOOS="darwin"
      GOPATH="/Users/df/go"
      GOPRIVATE=""
      GOPROXY="https://proxy.golang.org,direct"
      GOROOT="/usr/local/Cellar/go/1.15.2/libexec"
      GOSUMDB="sum.golang.org"
      GOTMPDIR=""
      GOTOOLDIR="/usr/local/Cellar/go/1.15.2/libexec/pkg/tool/darwin_amd64"
      GCCGO="gccgo"
      AR="ar"
      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/gd/ck6ncspn19115_7mxytyzw840000gp/T/go-build473384269=/tmp/go-build -gno-record-gcc-switches -fno-common"

Share the Go related settings you have added/edited

"go.useLanguageServer": true,

Describe the bug

When I save a file, it automatically adds any used package to import section. When that happens, I get a phantom error:

	"owner": "_generated_diagnostic_collection_name_#0",
	"severity": 8,
	"message": "could not import fmt (no package for import fmt)",
	"source": "compiler",

I still compiles, and if I comment/uncomment the import, the error goes away, but it's still very annoying.

Steps to reproduce the behavior:

  1. Paste following code - no errors
package main

import (
	"fmt"
)

func main() {
	fmt.Println(10)
}
  1. Remove line 8 and save a file - no errors
  2. Undo once - no errors
  3. Undo again - no errors
  4. Save a file - error above
  5. Add any code below the import - error still present
  6. Comment/uncomment import - error is gone

Screenshots or recordings

image
@stamblerre
Copy link
Contributor

Can you please share a gopls log from when you see this happen? Instructions on how to capture a log are here: https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md#capturing-logs.

@stamblerre stamblerre transferred this issue from golang/vscode-go Nov 24, 2020
@stamblerre stamblerre changed the title Frequent import error for standard library packages x/tools/gopls: frequent import error for standard library packages Nov 24, 2020
@stamblerre stamblerre added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Nov 24, 2020
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Nov 24, 2020
@stamblerre stamblerre added this to the gopls/vscode-go milestone Nov 24, 2020
@gopherbot gopherbot modified the milestones: gopls/vscode-go, Unreleased Nov 24, 2020
@RomanKornev
Copy link
Author

Here's the log:
gopls.log

@stamblerre
Copy link
Contributor

It looks like you delete and then replace the full content of the file in this log. My guess is that this is a bug that is actually fixed in Go 1.16. If you're willing to try building Go 1.16 from source, you can confirm that way (https://golang.org/doc/install/source).

Another way to test this out would be to add something like os.Exit(0) to your main function after and hit save. If things go back to working after that, then this bug has already been fixed in 1.16.

@stamblerre stamblerre moved this from Critical to Needs Triage in vscode-go: gopls by default Nov 25, 2020
@stamblerre stamblerre moved this from Needs Triage to Waiting for Info in vscode-go: gopls by default Nov 25, 2020
@RomanKornev
Copy link
Author

Adding os.Exit(0) did not fix the issue.
Here's me reproducing it on WSL Ubuntu as well. First time it worked fine, but second time it failed to import. As you can see, I'm not replacing the whole file:
2020-11-26 00 51 14
go version go1.15.5 linux/amd64
golang.org/x/tools/gopls v0.5.3
win10_wsl.log

@stamblerre
Copy link
Contributor

Thanks for the update. It's still a little tricky to see exactly what's going on here, so I will now have to ask you to try reproducing with Go 1.16. Since it's not yet released, you will have to follow the steps for building Go from source here: https://golang.org/doc/install/source.

If the issue persists with Go 1.16, then there is probably a gopls bug somewhere here.

@stamblerre
Copy link
Contributor

One thing to note is that you may be able to resolve the problem by creating a module (go mod init) in this directory. I believe there is a bug here with the way this package is being treated since it is both outside of GOPATH and outside of a module. I will also check if I can reproduce this myself with Go 1.15.

@stamblerre stamblerre changed the title x/tools/gopls: frequent import error for standard library packages x/tools/gopls: excessive packages.Load calls with an ad-hoc package outside of GOPATH/module Nov 25, 2020
@stamblerre stamblerre removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Nov 25, 2020
@stamblerre stamblerre moved this from Waiting for Info to Critical in vscode-go: gopls by default Nov 25, 2020
@RomanKornev
Copy link
Author

Seems to be fixed in 1.16. Unable to reproduce on go version devel +926994fd7c Thu Nov 26 21:10:09 2020 +0000 darwin/amd64

@gopherbot
Copy link

Change https://golang.org/cl/274443 mentions this issue: internal/lsp: don't reload invalid build configurations unconditionally

@stamblerre stamblerre self-assigned this Dec 3, 2020
vscode-go: gopls by default automation moved this from Critical to Done Dec 3, 2020
This was referenced Dec 3, 2020
Closed
Closed
@gopherbot
Copy link

Change https://golang.org/cl/275436 mentions this issue: internal/lsp: don't reload invalid build configurations unconditionally

@stamblerre stamblerre modified the milestones: gopls/v0.6.0, gopls/v0.5.5 Dec 4, 2020
gopherbot pushed a commit to golang/tools that referenced this issue Dec 4, 2020
@stamblerre
internal/lsp: don't reload invalid build configurations unconditionally
2527e7e 
Previously, we would always reload views with invalid build
configurations on every call to reloadWorkspace, even if the metadata
had no reason to be treated as invalid.

Fixes golang/go#42813

Change-Id: I9e0e493228916262908b81bc1b1ab1eb4e4eca9e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274443
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
(cherry picked from commit 2ecf2a5)
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275436
Run-TryBot: Robert Findley <rfindley@google.com>
marwan-at-work pushed a commit to marwan-at-work/tools that referenced this issue Dec 23, 2020
@stamblerre @marwan-at-work
internal/lsp: don't reload invalid build configurations unconditionally
eb95937 
Previously, we would always reload views with invalid build
configurations on every call to reloadWorkspace, even if the metadata
had no reason to be treated as invalid.

Fixes golang/go#42813

Change-Id: I9e0e493228916262908b81bc1b1ab1eb4e4eca9e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274443
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@golang golang locked and limited conversation to collaborators Dec 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
No open projects
vscode-go: gopls by default
  
Done
Milestone
gopls/v0.5.5
Development

No branches or pull requests
3 participants
@RomanKornev @stamblerre @gopherbot