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: v0.11.0 fails to find callers/references when compilation error in anciliary directory in a workspace #57727

Closed
Seefooo opened this issue Jan 10, 2023 · 5 comments
Closed

x/tools/gopls: v0.11.0 fails to find callers/references when compilation error in anciliary directory in a workspace #57727

Seefooo opened this issue Jan 10, 2023 · 5 comments
Labels
gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone
gopls/v0.12.0

Comments

@Seefooo
Copy link

Seefooo commented Jan 10, 2023

gopls version

gopls version
golang.org/x/tools/gopls v0.11.0
    golang.org/x/tools/gopls@v0.11.0 h1:/nvKHdTtePQmrv9XN3gIUN9MOdUrKzO/dcqgbG6x8EY=

go env

go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ygamal/.cache/go-build"
GOENV="/home/ygamal/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/ygamal/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/ygamal/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.18"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.18/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18.1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/ygamal/workspace/maglev/go.mod"
GOWORK="/home/ygamal/workspace/maglev/go.work"
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=/tmp/go-build753607085=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I updated from v0.10.1 to v0.11.0. Executing commands to get References or Callers will fail with a workspace error. Some of the our directories in src fail to build as they have an odd build setup that requires some external script to succeed.

  • gopls@v0.10.1 - gopls sees the build failures and I can see them being passed in some of the initial setup when introspecting the LSP comms between vim-go & gopls. When doing GoReferrers or GoCallers it doesn't seem to complain about the workspace errors, even though they have not really been fixed.
  • gopls@v0.11.0 - gopls sees the same build failures as above. When doing GoReferrers or GoCallers it still returns the same workspace loading failure.

The compilation failure is on a completely unrelated directory from what I can tell with some basic code poking.

What did you expect to see?

directories which are compiling to still be referable to/used by gopls.

What did you see instead?

gopls seems to ignore any workspace with compilation error in any of its directories, when it came to those calls. Finding Definitions seems to work still though.

Editor and settings

vim-go using gopls for pretty much everything. Using a go.work file also.

I can include logs or the LSP introspection if needed...but I am wondering if this is a bug or if this the correct expectation and v0.10.1 behavior was incidental. It makes gopls very difficult to use for larger projects, especially when bazel is involved, if this is the expected behavior.
@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 Jan 10, 2023
@gopherbot gopherbot added this to the Unreleased milestone Jan 10, 2023
@adonovan adonovan added NeedsFix The path to resolution is known, but the work has not been done. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed NeedsFix The path to resolution is known, but the work has not been done. labels Jan 12, 2023
@adonovan adonovan modified the milestones: Unreleased, gopls/v0.12.0 Jan 12, 2023
@Seefooo
Copy link
Author

Seefooo commented Jan 19, 2023 •
edited

Any thoughts on this? I am concerned with gopls being more restrictive about other packages' status in workspace, its going to make our life a lot harder, especially for bazel users.

@tooltitude-support
Copy link

@Seefooo We have an alternative implementation of find usages for vscode: https://marketplace.visualstudio.com/items?itemName=tooltitudeteam.tooltitude It's error resistant (we made it this way from the start).

P.S. This implementation works via a code lens, so that we could augment gopls, not via a shortcut.

@Seefooo
Copy link
Author

Seefooo commented Mar 1, 2023

@Seefooo We have an alternative implementation of find usages for vscode: https://marketplace.visualstudio.com/items?itemName=tooltitudeteam.tooltitude It's error resistant (we made it this way from the start).

P.S. This implementation works via a code lens, so that we could augment gopls, not via a shortcut.

Appreciate it, but i don't use vscode...

@adonovan
Copy link
Member

@Seefooo Unfortunately there isn't really enough information in this issue for me to reproduce this issue. I haven't personally encountered it, and I just now added compilation errors to a file and to one of its dependencies, and was able to use the 'references' feature successfully both within and across these files.

The design of gopls is certainly intended to provide good information in the presence of syntax errors and type errors. Parser error recovery could be better, but generally that affects only the downstream parts of a single file, not the whole workspace's reference index.

There has been a lot of development on gopls since v0.11 to fix bugs and improve performance, and we hope to release v0.12.0 next week. Would you be interested in trying out the v0.12.0-pre.2 pre-release?

Without more detail on how to reproduce this issue, I'm going to close this for now.

@Seefooo
Copy link
Author

Seefooo commented Aug 21, 2023 •
edited

Apologize about the long delay/response was out on a long leave, I can confirm that v0.12 & v0.13 do not exhibit this behavior anymore! (Just in case anyone else runs into a similar issue)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
gopls/v0.12.0
Development

No branches or pull requests
4 participants
@adonovan @gopherbot @Seefooo @tooltitude-support