b9adce94b7
The documentSymbols handler joined syntax information with type information, meaning that it was only able to satisfy requests for files in valid workspace packages. However, the value added by type information was limited, and in many cases could be derived from syntax alone. For example, while generating symbols for a const declaration, we don't need the type checker to tell us that the symbol kind is const. Refactor the documentSymbols handler to derive symbols from syntax alone. This leads to some simplifications from the code, in addition to eliminating the dependency on package data. Also, simplify symbol details to just use types.ExprString, which includes some missing information such as function return values. Also, update handling to support Go 1.18 type embedding in interfaces. Notably, this reverts decisions like golang/go#31202, in which we went to effort to make the symbol kind more accurate. In my opinion (and the opinion expressed in golang/go#52797), the cost of requiring type information is not worth the minor improvement in accuracy of the symbol kind, which (as far as I know) is only used for UI elements. To facilitate testing (and start to clean up the test framework), make several simplifications / improvements to the marker tests: - simplify the collection of symbol data - eliminate unused marks - just use cmp.Diff for comparing results - allow for arbitrary nesting of symbols. - remove unnecessary @symbol annotations from workspace_symbol tests -- their data is not used by workspace_symbol handlers - remove Symbol and WorkspaceSymbol handlers from source_test.go. On inspection, these handlers were redundant with lsp_test.go. Notably, the collection and assembly of @symbol annotations is still way too complicated. It would be much simpler to just have a single golden file summarizing the entire output, rather than weaving it together from annotations. However, I realized this too late, and so it will have to wait for a separate CL. Fixes golang/go#52797 Fixes golang/vscode-go#2242 Updates golang/go#54845 Change-Id: I3a2c2d39f59f9d045a6cedf8023ff0c80a69d974 Reviewed-on: https://go-review.googlesource.com/c/tools/+/405254 gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com> Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Alan Donovan <adonovan@google.com> |
||
|---|---|---|
| .. | ||
| api-diff | ||
| doc | ||
| integration/govim | ||
| internal | ||
| release | ||
| test | ||
| README.md | ||
| go.mod | ||
| go.sum | ||
| main.go | ||
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:
go install golang.org/x/tools/gopls@latest
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.
The following table shows the final gopls version that supports being built at a given Go Version. Any more recent Go versions missing from this table can still be built with the latest version of gopls.
| Go Version | Final gopls Version With Support |
|---|---|
| Go 1.12 | gopls@v0.7.5 |
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 is not officially
supported, but Bazel support is in development (see
bazelbuild/rules_go#512).
You can follow these instructions
to configure your gopls to work with Bazel.