• Is the module that contains the package already in your go.mod, and already in your module cache?
• can you capture a gopls log (I don't know nvim-specific instruction, but I guess this involves passing args in the gopls language server command setting following this general instruction.

1. yeah, the package has already in go.mod, has ready in cache
2. here is the gopls debug log
   gopls.log

i alse have this problem, and I solved it temporarily by restarting lsp

@jinzhongjia it doesn't work for me -,-
gopls works well beside this issue, i this it may works in a lazy loading model.

@jinzhongjia it doesn't work for me -,- gopls works well beside this issue, i this it may works in a lazy loading model.

now , i try golangci-lint,and it works very well

@jinzhongjia thx for your answer, is your edit is neovim/vim?

I have tried it just now, I found that it has it's own language server named golangci-lint-langserver,but it seems does't work in neovim(nvim-lspconfig).

@jinzhongjia thx for your answer, is your edit is neovim/vim?

I have tried it just now, I found that it has it's own language server named golangci-lint-langserver,but it seems does't work in neovim.

you need install golangci-lint and golangci-lint-langserver,but the golangci-lint-langserver no function Lspsaga hover_doc

when u have installed them ,you just add require("lspconfig").golangci_lint_ls.setup to your config

and now , i am back to gopls

and now , i am back to gopls

I can't stand without hover_doc

Hi! Can you start gopls with the -debug=localhost:8098 option and visit http://localhost:8098/trace/textDocument/completion. Can you share the trace of what gopls is doing during your slowest completion?

My theory of the problem is as follows: typing in an import path invalidates package metadata (because the import graph may have changed), which has a ripple effect of invalidation. Completion must wait for the go command and follow-up type-checking. But import completion should not require type-checking, so we should be able to bypass this.

This may have been a regression caused by work on invalidation.

@3Xpl0it3r there is something I don't understand in your logs: why earlier requests are completing rather than being canceled. I can't see enough information to understand why. Would you be willing to build and use a gopls branch that has additional logging, so that we can gather more information?

Hi! Can you start gopls with the -debug=localhost:8098 option and visit http://localhost:8098/trace/textDocument/completion. Can you share the trace of what gopls is doing during your slowest completion?

here is the trace information

@3Xpl0it3r there is something I don't understand in your logs: why earlier requests are completing rather than being canceled. I can't see enough information to understand why. Would you be willing to build and use a gopls branch that has additional logging, so that we can gather more information?

ofcourse, which branch should I use?
my curren gopls version is

➜  ~ gopls version
golang.org/x/tools/gopls v0.9.5
    golang.org/x/tools/gopls@v0.9.5 h1:F3TO5th6TUg40FHrpxZfMkMlVaaTmByeEvylgVHGH2A=
➜  ~ 

My theory of the problem is as follows: typing in an import path invalidates package metadata (because the import graph may have changed), which has a ripple effect of invalidation. Completion must wait for the go command and follow-up type-checking. But import completion should not require type-checking, so we should be able to bypass this.

This may have been a regression caused by work on invalidation.

it there any option in configure can skip this ?

@3Xpl0it3r this is the issue: as you are typing, your LSP client is asking for things like documentHighlight on each keypress. For gopls, this involves computing type information, which can take time. But on subsequent keypresses your client does not cancel the requests from older versions, so gopls does not proceed to processing the next keypress until it is done with the earlier documentHighlight request.

Most other LSP clients cancel requests relating to older file versions, when a new version arrives. I suspect that your client should do the same.

Here's a relevant section of the LSP spec:

/**
	 * The server detected that the content of a document got
	 * modified outside normal conditions. A server should
	 * NOT send this error code if it detects a content change
	 * in it unprocessed messages. The result even computed
	 * on an older state might still be useful for the client.
	 *
	 * If a client decides that a result is not of any use anymore
	 * the client should cancel the request.
	 */
	export const ContentModified: [integer](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#integer) = -32801;

Per my reading, this is saying that if the client doesn't explicitly cancel a request, we should continue to process it with the older content. In light of this, I think this is a client bug: the client should cancel the older requests if they are no longer needed.