History

Muir Manders b579874149 lsp/completion: reorganize how we track candidate type mods "type mod" refers to agglutinative expressions such as dereference "", invocation "()", and slicing "[:]". When considering an object as a completion candidate, we check whether applying a type mod would make it a better candidate. Previously we tracked the type mods we wanted to apply to a candidate by setting bool fields. Now instead we keep a slice of the type mods. This has two main advantages: - The mods are now ordered which will allow us to format candidates properly when the same mods can appear in different order (e.g. "<-foo" or <-foo"). - We can now record any mod multiple times allowing for "<-<-foo" or "foo()()". I changed the formatting code to always create a snippet object since that made things simpler. I had to tweak a few snippet helper methods to accept a snippet argument rather than creating a new snippet. This commit's only functional change is that we no longer show any type mods in candidate labels. For example, the user will now see "foo" in the completion popup instead of "foo". Showing the operators adds noise to the candidate list, and we didn't display them consistently. Updates golang/go#46045. Change-Id: I3ea7baa1ee2fee80a1f8cfe88cbae1093ae269ba Reviewed-on: https://go-review.googlesource.com/c/tools/+/323449 Run-TryBot: Muir Manders <muir@mnd.rs> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Trust: Rebecca Stambler <rstambler@golang.org>		2021-06-09 15:58:13 +00:00
..
doc	Revert "internal/lsp/cache: don't delete metadata until it's reloaded"	2021-06-02 19:45:53 +00:00
integration/govim	gopls/integration: remove obsolete code	2021-03-19 20:57:45 +00:00
internal	lsp/completion: reorganize how we track candidate type mods	2021-06-09 15:58:13 +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	gopls/test: it is safe to ignore json unmarshalling errors	2021-04-27 12:58:28 +00:00
README.md	gopls: clarify policy with respect to support for older Go versions	2021-05-03 16:07:20 +00:00
go.mod	gopls/internal/hooks: update for Staticcheck 2021.1	2021-05-25 18:39:40 +00:00
go.sum	gopls/internal/hooks: update for Staticcheck 2021.1	2021-05-25 18:39:40 +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. Per issue #39146, we attempt to maintain best-effort support for the last 4 major Go releases, but this support extends only to not breaking the build and avoiding easily fixable regressions.

Our extended support is enforced via continuous integration with older Go versions. This legacy Go CI may not block releases: test failures may be skipped rather than fixed. Furthermore, if a regression in an older Go version causes irreconcilable CI failures, we may drop support for that Go version in CI if it is 3 or 4 Go versions old.

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.