2018-09-24 16:05:51 -06:00
|
|
|
// Copyright 2018 The Go Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
2019-09-27 11:17:59 -06:00
|
|
|
// Package lsp implements LSP for gopls.
|
2018-09-24 16:05:51 -06:00
|
|
|
package lsp
|
|
|
|
|
|
|
|
import (
|
|
|
|
"context"
|
2020-03-09 12:17:49 -06:00
|
|
|
"fmt"
|
2018-09-27 09:28:20 -06:00
|
|
|
"sync"
|
2018-09-24 16:05:51 -06:00
|
|
|
|
|
|
|
"golang.org/x/tools/internal/jsonrpc2"
|
|
|
|
"golang.org/x/tools/internal/lsp/protocol"
|
2018-11-02 14:15:31 -06:00
|
|
|
"golang.org/x/tools/internal/lsp/source"
|
2019-11-21 22:52:09 -07:00
|
|
|
"golang.org/x/tools/internal/span"
|
2020-08-26 15:41:45 -06:00
|
|
|
errors "golang.org/x/xerrors"
|
2018-09-24 16:05:51 -06:00
|
|
|
)
|
|
|
|
|
2020-02-18 14:44:12 -07:00
|
|
|
const concurrentAnalyses = 1
|
|
|
|
|
2020-01-21 14:01:59 -07:00
|
|
|
// NewServer creates an LSP server and binds it to handle incoming client
|
|
|
|
// messages on on the supplied stream.
|
internal/lsp: refactor LSP server instantiation
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>
2020-01-21 17:34:50 -07:00
|
|
|
func NewServer(session source.Session, client protocol.Client) *Server {
|
|
|
|
return &Server{
|
2020-07-16 08:45:30 -06:00
|
|
|
delivered: make(map[span.URI]sentDiagnostics),
|
2020-07-28 18:05:06 -06:00
|
|
|
gcOptimizatonDetails: make(map[span.URI]struct{}),
|
2020-07-28 16:18:43 -06:00
|
|
|
watchedDirectories: make(map[span.URI]struct{}),
|
2020-07-16 08:45:30 -06:00
|
|
|
session: session,
|
|
|
|
client: client,
|
|
|
|
diagnosticsSema: make(chan struct{}, concurrentAnalyses),
|
2020-08-07 13:52:01 -06:00
|
|
|
progress: newProgressTracker(client),
|
2019-11-20 23:24:43 -07:00
|
|
|
}
|
2019-04-17 13:37:20 -06:00
|
|
|
}
|
|
|
|
|
2019-07-27 12:59:14 -06:00
|
|
|
type serverState int
|
|
|
|
|
|
|
|
const (
|
|
|
|
serverCreated = serverState(iota)
|
|
|
|
serverInitializing // set once the server has received "initialize" request
|
|
|
|
serverInitialized // set once the server has received "initialized" request
|
|
|
|
serverShutDown
|
|
|
|
)
|
|
|
|
|
2020-03-09 12:17:49 -06:00
|
|
|
func (s serverState) String() string {
|
|
|
|
switch s {
|
|
|
|
case serverCreated:
|
|
|
|
return "created"
|
|
|
|
case serverInitializing:
|
|
|
|
return "initializing"
|
|
|
|
case serverInitialized:
|
|
|
|
return "initialized"
|
|
|
|
case serverShutDown:
|
|
|
|
return "shutDown"
|
|
|
|
}
|
|
|
|
return fmt.Sprintf("(unknown state: %d)", int(s))
|
|
|
|
}
|
|
|
|
|
internal/lsp: refactor LSP server instantiation
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>
2020-01-21 17:34:50 -07:00
|
|
|
// Server implements the protocol.Server interface.
|
2019-03-28 19:06:01 -06:00
|
|
|
type Server struct {
|
2018-09-24 16:05:51 -06:00
|
|
|
client protocol.Client
|
2018-09-27 09:28:20 -06:00
|
|
|
|
2019-07-29 21:48:11 -06:00
|
|
|
stateMu sync.Mutex
|
|
|
|
state serverState
|
2018-09-27 09:28:20 -06:00
|
|
|
|
2019-05-15 10:24:49 -06:00
|
|
|
session source.Session
|
2019-03-14 15:19:01 -06:00
|
|
|
|
2020-08-10 11:19:11 -06:00
|
|
|
// rootURI is the root of the workspace opened in the editor (if any).
|
|
|
|
rootURI span.URI
|
|
|
|
|
2019-11-21 22:52:09 -07:00
|
|
|
// changedFiles tracks files for which there has been a textDocument/didChange.
|
2020-08-05 10:18:58 -06:00
|
|
|
changedFilesMu sync.Mutex
|
|
|
|
changedFiles map[span.URI]struct{}
|
2019-11-21 22:52:09 -07:00
|
|
|
|
2019-09-09 11:04:12 -06:00
|
|
|
// folders is only valid between initialize and initialized, and holds the
|
|
|
|
// set of folders to build views for when we are ready
|
|
|
|
pendingFolders []protocol.WorkspaceFolder
|
2019-11-20 23:24:43 -07:00
|
|
|
|
2020-07-28 16:18:43 -06:00
|
|
|
// watchedDirectories is the set of directories that we have requested that
|
|
|
|
// the client watch on disk. It will be updated as the set of directories
|
|
|
|
// that the server should watch changes.
|
|
|
|
watchedDirectoriesMu sync.Mutex
|
|
|
|
watchedDirectories map[span.URI]struct{}
|
|
|
|
watchRegistrationCount uint64
|
|
|
|
|
2019-11-20 23:24:43 -07:00
|
|
|
// delivered is a cache of the diagnostics that the server has sent.
|
|
|
|
deliveredMu sync.Mutex
|
|
|
|
delivered map[span.URI]sentDiagnostics
|
2020-02-18 14:44:12 -07:00
|
|
|
|
2020-07-28 18:05:06 -06:00
|
|
|
// gcOptimizationDetails describes the packages for which we want
|
|
|
|
// optimization details to be included in the diagnostics. The key is the
|
|
|
|
// directory of the package.
|
|
|
|
gcOptimizationDetailsMu sync.Mutex
|
|
|
|
gcOptimizatonDetails map[span.URI]struct{}
|
2020-07-16 08:45:30 -06:00
|
|
|
|
2020-02-18 14:44:12 -07:00
|
|
|
// diagnosticsSema limits the concurrency of diagnostics runs, which can be expensive.
|
|
|
|
diagnosticsSema chan struct{}
|
2020-03-12 14:31:00 -06:00
|
|
|
|
2020-08-07 13:52:01 -06:00
|
|
|
progress *progressTracker
|
2019-11-20 23:24:43 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// sentDiagnostics is used to cache diagnostics that have been sent for a given file.
|
|
|
|
type sentDiagnostics struct {
|
2020-07-26 16:01:39 -06:00
|
|
|
id source.VersionedFileIdentity
|
2020-03-31 21:53:42 -06:00
|
|
|
sorted []*source.Diagnostic
|
2020-01-13 18:41:03 -07:00
|
|
|
withAnalysis bool
|
|
|
|
snapshotID uint64
|
2018-09-27 09:28:20 -06:00
|
|
|
}
|
|
|
|
|
2020-01-23 08:56:00 -07:00
|
|
|
func (s *Server) nonstandardRequest(ctx context.Context, method string, params interface{}) (interface{}, error) {
|
2020-01-10 15:54:47 -07:00
|
|
|
paramMap := params.(map[string]interface{})
|
|
|
|
if method == "gopls/diagnoseFiles" {
|
2020-01-11 21:59:57 -07:00
|
|
|
for _, file := range paramMap["files"].([]interface{}) {
|
2020-07-02 16:34:10 -06:00
|
|
|
snapshot, fh, ok, release, err := s.beginFileRequest(ctx, protocol.DocumentURI(file.(string)), source.UnknownKind)
|
|
|
|
defer release()
|
2020-02-13 11:46:49 -07:00
|
|
|
if !ok {
|
2020-01-10 15:54:47 -07:00
|
|
|
return nil, err
|
|
|
|
}
|
2020-02-13 11:46:49 -07:00
|
|
|
|
internal/lsp: read files eagerly
We use file identities pervasively throughout gopls. Prior to this
change, the identity is the modification date of an unopened file, or
the hash of an opened file. That means that opening a file changes its
identity, which causes unnecessary churn in the cache.
Unfortunately, there isn't an easy way to fix this. Changing the
cache key to something else, such as the modification time, means that
we won't unify cache entries if a change is made and then undone. The
approach here is to read files eagerly in GetFile, so that we know their
hashes immediately. That resolves the churn, but means that we do a ton
of file IO at startup.
Incidental changes:
Remove the FileSystem interface; there was only one implementation and
it added a fair amount of cruft. We have many other places that assume
os.Stat and such work.
Add direct accessors to FileHandle for URI, Kind, and Version. Most uses
of (FileHandle).Identity were for stuff that we derive solely from the
URI, and this helped me disentangle them. It is a *ton* of churn,
though. I can revert it if you want.
Change-Id: Ia2133bc527f71daf81c9d674951726a232ca5bc9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/237037
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-08 13:21:24 -06:00
|
|
|
fileID, diagnostics, err := source.FileDiagnostics(ctx, snapshot, fh.URI())
|
2020-01-10 10:29:37 -07:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
if err := s.client.PublishDiagnostics(ctx, &protocol.PublishDiagnosticsParams{
|
internal/lsp: read files eagerly
We use file identities pervasively throughout gopls. Prior to this
change, the identity is the modification date of an unopened file, or
the hash of an opened file. That means that opening a file changes its
identity, which causes unnecessary churn in the cache.
Unfortunately, there isn't an easy way to fix this. Changing the
cache key to something else, such as the modification time, means that
we won't unify cache entries if a change is made and then undone. The
approach here is to read files eagerly in GetFile, so that we know their
hashes immediately. That resolves the churn, but means that we do a ton
of file IO at startup.
Incidental changes:
Remove the FileSystem interface; there was only one implementation and
it added a fair amount of cruft. We have many other places that assume
os.Stat and such work.
Add direct accessors to FileHandle for URI, Kind, and Version. Most uses
of (FileHandle).Identity were for stuff that we derive solely from the
URI, and this helped me disentangle them. It is a *ton* of churn,
though. I can revert it if you want.
Change-Id: Ia2133bc527f71daf81c9d674951726a232ca5bc9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/237037
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-08 13:21:24 -06:00
|
|
|
URI: protocol.URIFromSpanURI(fh.URI()),
|
2020-01-10 10:29:37 -07:00
|
|
|
Diagnostics: toProtocolDiagnostics(diagnostics),
|
|
|
|
Version: fileID.Version,
|
|
|
|
}); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2020-01-10 15:54:47 -07:00
|
|
|
}
|
|
|
|
if err := s.client.PublishDiagnostics(ctx, &protocol.PublishDiagnosticsParams{
|
|
|
|
URI: "gopls://diagnostics-done",
|
|
|
|
}); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return struct{}{}, nil
|
|
|
|
}
|
2020-01-10 15:35:46 -07:00
|
|
|
return nil, notImplemented(method)
|
|
|
|
}
|
|
|
|
|
2020-04-09 20:37:52 -06:00
|
|
|
func notImplemented(method string) error {
|
2020-08-26 15:41:45 -06:00
|
|
|
return errors.Errorf("%w: %q not yet implemented", jsonrpc2.ErrMethodNotFound, method)
|
2018-09-27 09:28:20 -06:00
|
|
|
}
|
2020-01-23 08:56:00 -07:00
|
|
|
|
|
|
|
//go:generate helper/helper -d protocol/tsserver.go -o server_gen.go -u .
|