go/gopls
Rob Findley d463eb0e41 internal/lsp/cache: introduce a workspace abstraction
When incorporating the gopls.mod file, the invalidation logic for
workspace module information becomes quite complicated. For example:
 + if a modfile changes we should only invalidate if it is in the set of
   active modules
 + the set of active modules can be provided by either the filesystem or
   gopls.mod
 + if gopls.mod changes, we may gain or lose active modules in the
   workspace
 + if gopls.mod is *deleted*, we may need to walk the filesystem to
   actually find all active modules

Doing this with only concrete changes to the snapshot proved
prohibitively complex (at least for me), so a new workspace type is
introduced to manage the module state. This new abstraction is
responsible for tracking the set of active modules, the workspace
modfile, and the set of workspace directories. Its invalidation logic is
factored out of snapshot.clone, so that it can be tested and to
alleviate some of the growing complexity of snapshot.clone.

The workspace type is idempotent, allowing it to be shared across
snapshots without needing to use the cache. There is little benefit to
the cache in this case, since workspace module computation should be
infrequent, and the type itself consumes little memory.

This is made possible because the workspace type itself depends only on
file state, and therefore may be invalidated independently of the
snapshot. The new source.FileState interface is used in testing, and so
that the workspace module may be computed based on both the session file
state as well as the snapshot file state.

As a result of this change, the following improvements in functionality
are possible:
 + in the presence of a gopls.mod file, we avoid walking the filesystem
   to detect modules. This could be helpful for working in large
   monorepos or in GOPATH, when discovering all modules would be
   expensive.
 + The set of active modules should always be consistent with the
   gopls.mod file, likely fixing some bugs (for example, computing
   diagnostics for modfiles that shouldn't be loaded)

For golang/go#41837

Change-Id: I2da888c097748b659ee892ca2d6b3fbe29c1942e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/261237
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Robert Findley <rfindley@google.com>
2020-10-30 19:58:30 +00:00
..
doc internal/lsp: use the go command to fix go.mod files 2020-10-28 22:47:54 +00:00
integration all: replace 'the the ' with 'the ' 2020-09-21 21:00:52 +00:00
internal internal/lsp/cache: introduce a workspace abstraction 2020-10-30 19:58:30 +00:00
test internal/lsp: run marker tests in multi-module mode 2020-09-25 18:05:33 +00:00
README.md fix: using section links to IDE specific doc 2019-12-17 14:12:49 +00:00
go.mod all: update all dependencies to latest pseudoversions 2020-10-22 03:59:29 +00:00
go.sum all: update all dependencies to latest pseudoversions 2020-10-22 03:59:29 +00:00
main.go gopls: add the link to the gopls/README.md 2020-02-03 22:28:49 +00:00

README.md

gopls documentation

gopls (pronounced: "go please") is the official language server for the Go language.

Status

It is currently in alpha, so it is not stable.

You can see more information about the status of gopls and its supported features here.

Roadmap

The current goal is a fully stable build with the existing feature set, aiming for the first half of 2020, with release candidates earlier in the year.

This will be the first build that we recommend people use, and will be tagged as the 1.0 version. You can see the set of things being worked on in the 1.0 milestone, in general we are focused on stability, specifically, making sure we have a reliable service that produces an experience in module mode that is not a retrograde step from the old tools in GOPATH mode.

There is also considerable effort being put into testing in order to make sure that we both have a stable service and also that we do not regress after launch.

While we may continue to accept contributions for new features, they may be turned off behind a configuration flag if they are not yet stable. See the gopls unplanned milestone for deprioritized features.

This is just a milestone for gopls itself. We work with editor integrators to make sure they can use the latest builds of gopls, and will help them use the 1.0 version as soon as it is ready, but that does not imply anything about the stability, supported features or version of the plugins.

Using

In general you should not need to know anything about gopls, it should be integrated into your editor for you.

To install for your specific editor you can follow the following instructions

See the user guide for more information, including the how to install gopls by hand if you need.

Issues

If you are having issues with gopls, please first check the known issues before following the troubleshooting guide. If that does not give you the information you need, reach out to us.

You can chat with us on:

If you think you have an issue that needs fixing, or a feature suggestion, then please make sure you follow the steps to file an issue with the right information to allow us to address it.

If you need to talk to us directly (for instance to file an issue with confidential information in it) you can reach out directly to @stamblerre or @ianthehat.

More information

If you want to know more about it, have an unusual use case, or want to contribute, please read the following documents