c29062fe1d
Previously, the process of instantiating and running the LSP server was
sharded across the lsp, protocol, and cmd packages, and this resulted in
some APIs that are hard to work with. For example, it's hard to guess
the difference between lsp.NewClientServer, lsp.NewServer,
protocol.NewServer (which returns a client), and protocol.NewClient
(which returns a server).
This change reorganizes Server instantiation as follows:
+ The lsp.Server is now purely an implementation of the protocol.Server
interface. It is no longer responsible for installing itself into the
jsonrpc2 Stream, nor for running itself.
+ A new package 'lsprpc' is added, to implement the logic of binding an
incoming connection to an LSP server session. This is put in a
separate package for lack of a clear home: it didn't really
philosophically belong in any of the lsp, cmd, or protocol packages.
We can perhaps move it to cmd in the future, but I'd like to keep it
as a separate package while I develop request forwarding.
simplified import graph:
jsonrpc2 ⭠ lsprpc ⭠ cmd
⭩ ⭦
lsp (t.b.d. client tests)
⭩ ⭨
protocol source
+ The jsonrpc2 package is extended to have a minimal API for running a
'StreamServer': something analogous to an HTTP server that listens
for new connections and delegates to a handler (but we couldn't use
the word 'Handler' for this delegate as it was already taken).
After these changes, I hope that the concerns of "serving the LSP",
"serving jsonrpc2", and "installing the LSP on jsonrpc2" are more
logically organized, though one legitimate criticism is that the word
'Server' is still heavily overloaded.
This change prepares a subsequent change which hijacks the jsonrpc2
connection when forwarding messages to a shared gopls instance.
To test this change, the following improvements are made:
+ A servertest package is added to make it easier to run a test against
an in-process jsonrpc2 server. For now, this uses TCP but it could
easily be modified to use io.Pipe.
+ cmd tests are updated to use the servertest package. Unfortunately it
wasn't yet possible to eliminate the concept of `remote=internal` in
favor of just using multiple sessions, because view initialization
involves calling both `go env` and `packages.Load`, which slow down
session startup significantly. See also golang.org/issue/35968.
Instead, the syntax for `-remote=internal` is modified to be
`-remote=internal@127.0.0.1:12345`.
+ An additional test for request cancellation is added for the
sessionserver package. This test uncovered a bug: when calling
Canceller.Cancel, we were using id rather than &id, which resulted in
incorrect json serialization (as only the pointer receiver implements
the json.Marshaller interface).
Updates golang/go#34111
Change-Id: I75c219df634348cdf53a9e57839b98588311a9ef
Reviewed-on: https://go-review.googlesource.com/c/tools/+/215742
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
|
||
|---|---|---|
| .. | ||
| doc | ||
| integration | ||
| internal/hooks | ||
| test | ||
| go.mod | ||
| go.sum | ||
| main.go | ||
| 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:
- the golang-tools mailing list
- the #gopls slack channel on the gophers slack
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