History

Heschi Kreinick 1e7abacf3b internal/lsp: refactor go command error handling Our handling of go command errors was cobbled together, leading to unexpected gaps and duplication. Refactor it to be more coherent. Our goal is to turn every go command error into a diagnostic in the relevant location. The errors don't contain error positions, so we have to guess where they belong using the module names mentioned in the error. If we can't find any reference to those modules, we are forced to add diagnostics to all go.mod files. I may have destroyed the intent of TestMultiModule_OneBrokenModule but I'm not sure what to do about it. Some cleanup along the way: - Stop parsing modfile.Parse error text: it returns structured errors and we can just use them. - Return CriticalErrors from awaitLoadedAllErrors, and do error extraction lower in the stack. This prevents a ridiculous situation where initialize formed a CriticalError, then awaitLoadedAllErrors returned just its MainError, and then GetCriticalError parsed out a new CriticalError from the MainError we got from a CriticalError. - In initialize, return modDiagnostics even if load succeeds: we are missing packages and should not silently fail, I think? - During testing I tripped over ApplyQuickFixes' willingness to not actually do anything, so I made that an error. Fixes golang/go#44132. I may also have fixed golang/go#44204 but I haven't checked. Change-Id: Ibf819d0f044d4f99795978a28b18915893e50c88 Reviewed-on: https://go-review.googlesource.com/c/tools/+/291192 Trust: Heschi Kreinick <heschi@google.com> Run-TryBot: Heschi Kreinick <heschi@google.com> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>		2021-02-16 21:26:54 +00:00
..
doc	internal/lsp/command: stub out the ListKnownPackages and AddImport commands	2021-02-11 00:57:35 +00:00
integration	all: replace all usages of os/exec with golang.org/x/sys/execabs	2021-01-19 22:25:03 +00:00
internal	internal/lsp: refactor go command error handling	2021-02-16 21:26:54 +00:00
release	all: replace all usages of os/exec with golang.org/x/sys/execabs	2021-01-19 22:25:03 +00:00
test	internal/lsp: update to latest version of LSP protocol	2021-02-02 11:32:59 +00:00
README.md	gopls: factor out advanced documentation from the README	2021-01-22 17:08:14 +00:00
go.mod	all: upgrade all dependencies, if possible	2021-02-03 19:28:29 +00:00
go.sum	all: upgrade all dependencies, if possible	2021-02-03 19:28:29 +00:00
main.go	gopls: use standard command doc comment format	2021-01-08 18:12:31 +00:00

README.md

`gopls`, the Go language server

gopls (pronounced "Go please") is the official Go language server developed by the Go team. It provides IDE features to any LSP-compatible editor.

You should not need to interact with gopls directly--it will be automatically integrated into your editor. The specific features and settings vary slightly by editor, so we recommend that you proceed to the documentation for your editor below.

Editors

To get started with gopls, install an LSP plugin in your editor of choice.

If you use gopls with an editor that is not on this list, please let us know by filing an issue or modifying this documentation.

Installation

For the most part, you should not need to install or update gopls. Your editor should handle that step for you.

If you do want to get the latest stable version of gopls, change to any directory that is both outside of your GOPATH and outside of a module (a temp directory is fine), and run:

GO111MODULE=on go get golang.org/x/tools/gopls@latest

NOTE: Do not use the -u flag, as it will update your dependencies to incompatible versions.

Learn more in the advanced installation instructions.

Setting up your workspace

gopls supports both Go module and GOPATH modes, but if you are working with multiple modules or uncommon project layouts, you will need to specifically configure your workspace. See the Workspace document for information on supported workspace layouts.

Configuration

You can configure gopls to change your editor experience or view additional debugging information. Configuration options will be made available by your editor, so see your editor's instructions for specific details. A full list of gopls settings can be found in the Settings documentation.

Environment variables

gopls inherits your editor's environment, so be aware of any environment variables you configure. Some editors, such as VS Code, allow users to selectively override the values of some environment variables.

Troubleshooting

If you are having issues with gopls, please follow the steps described in the troubleshooting guide.

Supported Go versions and build systems

gopls follows the Go Release Policy, meaning that it officially supports the last 2 major Go releases. Though we try not to break older versions, we do not prioritize issues only affecting legacy Go releases.

gopls currently only supports the go command, so if you are using a different build system, gopls will not work well. Bazel support is currently blocked on bazelbuild/rules_go#512.