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: missing textDocument/references results at first, in emacs+eglot+xrefs #53499

Closed
adonovan opened this issue Jun 22, 2022 · 2 comments
Labels
Documentation 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

Comments

@adonovan
Copy link
Member

adonovan commented Jun 22, 2022

  1. Start a new Emacs instance using go-mode, eglot, xrefs, and gopls.
  2. Find-file xtools/internal/lsp/cache/cache.go, where xtools is a git clone of golang.org/x/tools.
  3. Place cursor at func New identifier and call the xref-find-references Lisp command.
  4. Observe no results.
  5. Find-file xtools/internal/lsp/cmd/cmd.go then immediately kill the buffer.
  6. Repeat steps 2 and 3
  7. Observe these (correct) results:
internal/lsp/cmd/capabilities_test.go
46: 	c.Server = lsp.NewServer(cache.New(app.options).NewSession(ctx), c.Client)
internal/lsp/cmd/cmd.go
289: 		connection.Server = lsp.NewServer(cache.New(app.options).NewSession(ctx), connection.Client)
internal/lsp/cmd/serve.go
104: 		ss = lsprpc.NewStreamServer(cache.New(s.app.options), isDaemon)

This history of opened buffers should not affect the results of this query.

My first question at this point is: is the problem in Emacs or gopls? I tried to answer that by using the command-line client, but that exits zero with no output even when Emacs is working, which looks like a separate bug:

$ go run ./gopls/ --remote=localhost:8091 references internal/lsp/cache/cache.go:31:6
$

(Adding -v to the latter command displays a number of info logs concerning "go/packages.Load". Is the command-line tool trying to do the analysis itself instead of sending a request to the server?)

@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 Jun 22, 2022
@gopherbot gopherbot added this to the Unreleased milestone Jun 22, 2022
@dle8 dle8 added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 22, 2022
@dle8 dle8 modified the milestones: Unreleased, gopls/later Jun 22, 2022
@muirdm
Copy link

muirdm commented Jun 28, 2022

It works properly for me in Emacs/lsp-mode (and eglot). Based on the log events you see in Emacs, what packages is gopls loading when it starts up? For example In my *EGLOT ... buffer I see this message (cleaned up for readability):

2022/06/27 19:31:59 go/packages.Load
	snapshot=0
	directory=/Users/muir/projects/tools
	query=[builtin golang.org/x/tools/...]
	packages=561

I wonder if your workspace is misconfigured somehow and gopls is not loading all the packages on startup.

@adonovan adonovan self-assigned this Aug 26, 2022
@adonovan
Copy link
Member Author

adonovan commented Jun 4, 2024

Can't repro. I'm almost certain we (= @findleyr) fixed this during all the zero-config work.

@adonovan adonovan closed this as completed Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation 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
Development

No branches or pull requests

4 participants