x/tools/gopls: pause gopls from command line and enable it back

[igadmg]

Is it possible to switch off/on gopls from command line or from go program? I have a heavy source code generation step in my project and it drives gopls crazy - it start to report fantom errors, when it picks changes from generated files being updated.
So I'd like to pause gopls for a while.

Also maybe there is a bug when it picks source changes form a file, but if that file is updated while gopls is procesing it gopls does not reevaluate new changes.

[adonovan]

When you say phantom errors, do you mean gopls reports compilation errors that go build does not? If so, that indicates that its view of the file system has become inconsistent. The LSP model requires clients to notify servers of all file state changes, even changes made by external tools such as git checkout. VS Code is pretty good at this, but many clients do not implement the necessary file watching. (I often notice inconsistency with Emacs+eglot after a checkout, for example, and sadly the quickest workaround is to restart the server.) In recognition of this situation, we are currently developing a server-side file watcher that should reduce occurrences of such inconsistencies.

cc: @h9jiang

[igadmg]

Yes, my current workflo now is dump a lot of code to .go file, then run goimports on it to fix it. So looks like vs code notify lsp when I dump the code, but does not notify lsp when goimports finishes work. I can workaround it by dumping code to some temp file I think, maybt with some .go.tmp extension, if goimports would correctly work with it afterwards. There serrors go away after I manually open source files in vs code, soit notify lsp after that. But maybe can I somehow notify vscodes lsp about file changes from my tool?

Also sometimes LSP go mad and complain about some imports missing in my go.mod files, usually after I do go mod tidy and update of a lot of mod files in a project.

[adonovan]

Yes, my current workflo now is dump a lot of code to .go file, then run goimports on it to fix it. So looks like vs code notify lsp when I dump the code, but does not notify lsp when goimports finishes work. I can workaround it by dumping code to some temp file I think, maybt with some .go.tmp extension, if goimports would correctly work with it afterwards.

Why do you use goimports? gopls implements the source.organizeImports code action, which does the same thing more efficiently; most clients typically request it each time a file is saved.

There serrors go away after I manually open source files in vs code, soit notify lsp after that. But maybe can I somehow notify vscodes lsp about file changes from my tool?

The quickest way to do this may be to restart the server (unless your server startup--which primarily consists of running go list in your workspace--is particularly slow).

Also sometimes LSP go mad and complain about some imports missing in my go.mod files, usually after I do go mod tidy and update of a lot of mod files in a project.

Are you able to reproduce this? If so, please report the sequence of steps that you took.

[igadmg]

Why do you use goimports? gopls implements the source.organizeImports code action, which does the same thing more efficiently; most clients typically request it each time a file is saved.

Interesting, never was thinking about using gopls for that goimports was a first google search result on that topic.

Are you able to reproduce this? If so, please report the sequence of steps that you took.

I think you need quite big project, with a lot of packages added to go.work file. Then I use my tool to find every go.mod file and do go mod tidy, and go get -u all and usually after that gopls goes crazy. Restarting it from vs code does not help, but it fixes itself after 5-10 minutes, I think because vs code finally do some update
Or maybe that happens after I do go clean --cache on my project with a lot of go.work entities. yes I think go clean --cache is crucial step here.

[igadmg]

@adonovan I got that error again out of nowhere

golang.org/x/sys is not in your go.mod filego mod tidy
package cache
Package path: github.com/igadmg/goex/cache
Module: github.com/igadmg/goex
Language version: go1.25

Looking at gopls server logs, I can assume it can't get sources from my private repos.

go: github.com/igadmg/colonization_test tested by
	github.com/igadmg/colonization_test.test imports
	github.com/igadmg/gogen/test: cannot find module providing package github.com/igadmg/gogen/test: module github.com/igadmg/gogen/test: git ls-remote -q --end-of-options origin in D:\tmp\gomodcache\cache\vcs\c6c63b11bb48c8eff1a2679133aaf8233705768567aec1ff930458c514c834e6: exit status 128:
	FATAL ERROR: No supported authentication methods available (server sent: publickey)
	fatal: Could not read from remote repository.
	
	Please make sure you have the correct access rights
	and the repository exists.

But it looks sus because that is completely unrelated repo to the one where that error is produced.
On the other hand - I have my GOPRIVATE setup correctly in VS code, and in system environment variables, and have no difficulty updating these private packages from cli. So hard to tell why gopls complain.