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
|
|
|
// Copyright 2020 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.
|
|
|
|
|
|
|
|
// Package lsprpc implements a jsonrpc2.StreamServer that may be used to
|
|
|
|
// serve the LSP on a jsonrpc2 channel.
|
|
|
|
package lsprpc
|
|
|
|
|
|
|
|
import (
|
|
|
|
"context"
|
2020-02-19 08:18:21 -07:00
|
|
|
"encoding/json"
|
2020-02-06 17:50:37 -07:00
|
|
|
"fmt"
|
2020-02-18 10:47:19 -07:00
|
|
|
stdlog "log"
|
2020-02-06 17:50:37 -07:00
|
|
|
"net"
|
2020-02-09 12:44:03 -07:00
|
|
|
"os"
|
2020-02-18 10:47:19 -07:00
|
|
|
"os/exec"
|
2020-02-19 08:18:21 -07:00
|
|
|
"strconv"
|
|
|
|
"sync/atomic"
|
2020-02-10 09:34:13 -07:00
|
|
|
"time"
|
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
|
|
|
|
2020-02-06 17:50:37 -07:00
|
|
|
"golang.org/x/sync/errgroup"
|
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
|
|
|
"golang.org/x/tools/internal/jsonrpc2"
|
|
|
|
"golang.org/x/tools/internal/lsp"
|
2020-02-18 18:59:37 -07:00
|
|
|
"golang.org/x/tools/internal/lsp/cache"
|
2020-02-19 08:18:21 -07:00
|
|
|
"golang.org/x/tools/internal/lsp/debug"
|
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
|
|
|
"golang.org/x/tools/internal/lsp/protocol"
|
2020-02-19 08:18:21 -07:00
|
|
|
"golang.org/x/tools/internal/telemetry/log"
|
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
|
|
|
)
|
|
|
|
|
2020-02-18 10:47:19 -07:00
|
|
|
// AutoNetwork is the pseudo network type used to signal that gopls should use
|
|
|
|
// automatic discovery to resolve a remote address.
|
|
|
|
const AutoNetwork = "auto"
|
|
|
|
|
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
|
|
|
// The StreamServer type is a jsonrpc2.StreamServer that handles incoming
|
|
|
|
// streams as a new LSP session, using a shared cache.
|
|
|
|
type StreamServer struct {
|
|
|
|
withTelemetry bool
|
2020-02-19 08:18:21 -07:00
|
|
|
debug *debug.Instance
|
2020-02-19 08:17:48 -07:00
|
|
|
cache *cache.Cache
|
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
|
|
|
|
2020-02-19 08:18:21 -07:00
|
|
|
// serverForTest may be set to a test fake for testing.
|
2020-02-19 08:17:48 -07:00
|
|
|
serverForTest protocol.Server
|
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
|
|
|
}
|
|
|
|
|
2020-02-19 08:18:21 -07:00
|
|
|
var clientIndex, serverIndex int64
|
|
|
|
|
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
|
|
|
// NewStreamServer creates a StreamServer using the shared cache. If
|
|
|
|
// withTelemetry is true, each session is instrumented with telemetry that
|
|
|
|
// records RPC statistics.
|
2020-02-19 08:18:21 -07:00
|
|
|
func NewStreamServer(cache *cache.Cache, withTelemetry bool, debugInstance *debug.Instance) *StreamServer {
|
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
|
|
|
s := &StreamServer{
|
|
|
|
withTelemetry: withTelemetry,
|
2020-02-19 08:18:21 -07:00
|
|
|
debug: debugInstance,
|
2020-02-19 08:17:48 -07:00
|
|
|
cache: cache,
|
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
|
|
|
}
|
|
|
|
return s
|
|
|
|
}
|
|
|
|
|
2020-02-19 08:18:21 -07:00
|
|
|
// debugInstance is the common functionality shared between client and server
|
|
|
|
// gopls instances.
|
|
|
|
type debugInstance struct {
|
|
|
|
id string
|
|
|
|
debugAddress string
|
|
|
|
logfile string
|
2020-02-18 10:47:19 -07:00
|
|
|
goplsPath string
|
2020-02-19 08:18:21 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func (d debugInstance) ID() string {
|
|
|
|
return d.id
|
|
|
|
}
|
|
|
|
|
|
|
|
func (d debugInstance) DebugAddress() string {
|
|
|
|
return d.debugAddress
|
|
|
|
}
|
|
|
|
|
|
|
|
func (d debugInstance) Logfile() string {
|
|
|
|
return d.logfile
|
|
|
|
}
|
|
|
|
|
2020-02-18 10:47:19 -07:00
|
|
|
func (d debugInstance) GoplsPath() string {
|
|
|
|
return d.goplsPath
|
|
|
|
}
|
|
|
|
|
2020-02-19 08:18:21 -07:00
|
|
|
// A debugServer is held by the client to identity the remove server to which
|
|
|
|
// it is connected.
|
|
|
|
type debugServer struct {
|
|
|
|
debugInstance
|
|
|
|
// clientID is the id of this client on the server.
|
|
|
|
clientID string
|
|
|
|
}
|
|
|
|
|
|
|
|
func (s debugServer) ClientID() string {
|
|
|
|
return s.clientID
|
|
|
|
}
|
|
|
|
|
|
|
|
// A debugClient is held by the server to identify an incoming client
|
|
|
|
// connection.
|
|
|
|
type debugClient struct {
|
|
|
|
debugInstance
|
|
|
|
// session is the session serving this client.
|
|
|
|
session *cache.Session
|
|
|
|
// serverID is this id of this server on the client.
|
|
|
|
serverID string
|
|
|
|
}
|
|
|
|
|
|
|
|
func (c debugClient) Session() debug.Session {
|
|
|
|
return cache.DebugSession{Session: c.session}
|
|
|
|
}
|
|
|
|
|
|
|
|
func (c debugClient) ServerID() string {
|
|
|
|
return c.serverID
|
|
|
|
}
|
|
|
|
|
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
|
|
|
// ServeStream implements the jsonrpc2.StreamServer interface, by handling
|
|
|
|
// incoming streams using a new lsp server.
|
|
|
|
func (s *StreamServer) ServeStream(ctx context.Context, stream jsonrpc2.Stream) error {
|
2020-02-19 08:18:21 -07:00
|
|
|
index := atomic.AddInt64(&clientIndex, 1)
|
|
|
|
|
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
|
|
|
conn := jsonrpc2.NewConn(stream)
|
|
|
|
client := protocol.ClientDispatcher(conn)
|
2020-02-19 08:18:21 -07:00
|
|
|
session := s.cache.NewSession()
|
|
|
|
dc := &debugClient{
|
|
|
|
debugInstance: debugInstance{
|
|
|
|
id: strconv.FormatInt(index, 10),
|
|
|
|
},
|
|
|
|
session: session,
|
|
|
|
}
|
|
|
|
s.debug.State.AddClient(dc)
|
2020-02-21 15:31:45 -07:00
|
|
|
defer s.debug.State.DropClient(dc)
|
|
|
|
|
2020-02-19 08:17:48 -07:00
|
|
|
server := s.serverForTest
|
|
|
|
if server == nil {
|
2020-02-19 08:18:21 -07:00
|
|
|
server = lsp.NewServer(session, client)
|
2020-02-19 08:17:48 -07:00
|
|
|
}
|
2020-02-21 15:31:45 -07:00
|
|
|
// Clients may or may not send a shutdown message. Make sure the server is
|
|
|
|
// shut down.
|
|
|
|
// TODO(rFindley): this shutdown should perhaps be on a disconnected context.
|
|
|
|
defer server.Shutdown(ctx)
|
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
|
|
|
conn.AddHandler(protocol.ServerHandler(server))
|
|
|
|
conn.AddHandler(protocol.Canceller{})
|
|
|
|
if s.withTelemetry {
|
|
|
|
conn.AddHandler(telemetryHandler{})
|
|
|
|
}
|
2020-02-18 10:47:19 -07:00
|
|
|
executable, err := os.Executable()
|
|
|
|
if err != nil {
|
|
|
|
stdlog.Printf("error getting gopls path: %v", err)
|
|
|
|
executable = ""
|
|
|
|
}
|
2020-02-19 08:18:21 -07:00
|
|
|
conn.AddHandler(&handshaker{
|
2020-02-18 10:47:19 -07:00
|
|
|
client: dc,
|
|
|
|
debug: s.debug,
|
|
|
|
goplsPath: executable,
|
2020-02-19 08:18:21 -07:00
|
|
|
})
|
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
|
|
|
return conn.Run(protocol.WithClient(ctx, client))
|
|
|
|
}
|
2020-02-06 17:50:37 -07:00
|
|
|
|
|
|
|
// A Forwarder is a jsonrpc2.StreamServer that handles an LSP stream by
|
|
|
|
// forwarding it to a remote. This is used when the gopls process started by
|
|
|
|
// the editor is in the `-remote` mode, which means it finds and connects to a
|
|
|
|
// separate gopls daemon. In these cases, we still want the forwarder gopls to
|
|
|
|
// be instrumented with telemetry, and want to be able to in some cases hijack
|
|
|
|
// the jsonrpc2 connection with the daemon.
|
|
|
|
type Forwarder struct {
|
2020-02-10 09:34:13 -07:00
|
|
|
network, addr string
|
|
|
|
|
|
|
|
// Configuration. Right now, not all of this may be customizable, but in the
|
|
|
|
// future it probably will be.
|
2020-02-06 17:50:37 -07:00
|
|
|
withTelemetry bool
|
2020-02-10 09:34:13 -07:00
|
|
|
dialTimeout time.Duration
|
|
|
|
retries int
|
2020-02-19 08:18:21 -07:00
|
|
|
debug *debug.Instance
|
2020-02-18 10:47:19 -07:00
|
|
|
goplsPath string
|
2020-02-06 17:50:37 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// NewForwarder creates a new Forwarder, ready to forward connections to the
|
2020-02-10 09:34:13 -07:00
|
|
|
// remote server specified by network and addr.
|
2020-02-19 08:18:21 -07:00
|
|
|
func NewForwarder(network, addr string, withTelemetry bool, debugInstance *debug.Instance) *Forwarder {
|
2020-02-18 10:47:19 -07:00
|
|
|
gp, err := os.Executable()
|
|
|
|
if err != nil {
|
|
|
|
stdlog.Printf("error getting gopls path for forwarder: %v", err)
|
|
|
|
gp = ""
|
|
|
|
}
|
2020-02-21 15:31:45 -07:00
|
|
|
|
2020-02-06 17:50:37 -07:00
|
|
|
return &Forwarder{
|
2020-02-10 09:34:13 -07:00
|
|
|
network: network,
|
|
|
|
addr: addr,
|
2020-02-06 17:50:37 -07:00
|
|
|
withTelemetry: withTelemetry,
|
2020-02-10 09:34:13 -07:00
|
|
|
dialTimeout: 1 * time.Second,
|
|
|
|
retries: 5,
|
2020-02-19 08:18:21 -07:00
|
|
|
debug: debugInstance,
|
2020-02-18 10:47:19 -07:00
|
|
|
goplsPath: gp,
|
2020-02-06 17:50:37 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// ServeStream dials the forwarder remote and binds the remote to serve the LSP
|
|
|
|
// on the incoming stream.
|
|
|
|
func (f *Forwarder) ServeStream(ctx context.Context, stream jsonrpc2.Stream) error {
|
|
|
|
clientConn := jsonrpc2.NewConn(stream)
|
|
|
|
client := protocol.ClientDispatcher(clientConn)
|
|
|
|
|
2020-02-18 10:47:19 -07:00
|
|
|
netConn, err := f.connectToRemote(ctx)
|
2020-02-06 17:50:37 -07:00
|
|
|
if err != nil {
|
2020-02-18 10:47:19 -07:00
|
|
|
return fmt.Errorf("forwarder: connecting to remote: %v", err)
|
2020-02-06 17:50:37 -07:00
|
|
|
}
|
|
|
|
serverConn := jsonrpc2.NewConn(jsonrpc2.NewHeaderStream(netConn, netConn))
|
|
|
|
server := protocol.ServerDispatcher(serverConn)
|
|
|
|
|
|
|
|
// Forward between connections.
|
|
|
|
serverConn.AddHandler(protocol.ClientHandler(client))
|
|
|
|
serverConn.AddHandler(protocol.Canceller{})
|
|
|
|
clientConn.AddHandler(protocol.ServerHandler(server))
|
|
|
|
clientConn.AddHandler(protocol.Canceller{})
|
2020-02-09 12:44:03 -07:00
|
|
|
clientConn.AddHandler(forwarderHandler{})
|
2020-02-06 17:50:37 -07:00
|
|
|
if f.withTelemetry {
|
|
|
|
clientConn.AddHandler(telemetryHandler{})
|
|
|
|
}
|
|
|
|
g, ctx := errgroup.WithContext(ctx)
|
|
|
|
g.Go(func() error {
|
|
|
|
return serverConn.Run(ctx)
|
|
|
|
})
|
|
|
|
g.Go(func() error {
|
|
|
|
return clientConn.Run(ctx)
|
|
|
|
})
|
2020-02-19 08:18:21 -07:00
|
|
|
|
|
|
|
// Do a handshake with the server instance to exchange debug information.
|
|
|
|
index := atomic.AddInt64(&serverIndex, 1)
|
|
|
|
serverID := strconv.FormatInt(index, 10)
|
|
|
|
var (
|
|
|
|
hreq = handshakeRequest{
|
|
|
|
ServerID: serverID,
|
|
|
|
Logfile: f.debug.Logfile,
|
2020-02-18 10:47:19 -07:00
|
|
|
DebugAddr: f.debug.ListenedDebugAddress,
|
|
|
|
GoplsPath: f.goplsPath,
|
2020-02-19 08:18:21 -07:00
|
|
|
}
|
|
|
|
hresp handshakeResponse
|
|
|
|
)
|
|
|
|
if err := serverConn.Call(ctx, handshakeMethod, hreq, &hresp); err != nil {
|
2020-02-18 10:47:19 -07:00
|
|
|
log.Error(ctx, "forwarder: gopls handshake failed", err)
|
|
|
|
}
|
|
|
|
if hresp.GoplsPath != f.goplsPath {
|
|
|
|
log.Error(ctx, "", fmt.Errorf("forwarder: gopls path mismatch: forwarder is %q, remote is %q", f.goplsPath, hresp.GoplsPath))
|
2020-02-19 08:18:21 -07:00
|
|
|
}
|
|
|
|
f.debug.State.AddServer(debugServer{
|
|
|
|
debugInstance: debugInstance{
|
|
|
|
id: serverID,
|
|
|
|
logfile: hresp.Logfile,
|
|
|
|
debugAddress: hresp.DebugAddr,
|
2020-02-18 10:47:19 -07:00
|
|
|
goplsPath: hresp.GoplsPath,
|
2020-02-19 08:18:21 -07:00
|
|
|
},
|
|
|
|
clientID: hresp.ClientID,
|
|
|
|
})
|
2020-02-06 17:50:37 -07:00
|
|
|
return g.Wait()
|
|
|
|
}
|
2020-02-09 12:44:03 -07:00
|
|
|
|
2020-02-18 10:47:19 -07:00
|
|
|
func (f *Forwarder) connectToRemote(ctx context.Context) (net.Conn, error) {
|
|
|
|
var (
|
|
|
|
netConn net.Conn
|
|
|
|
err error
|
|
|
|
network, address = f.network, f.addr
|
|
|
|
)
|
|
|
|
if f.network == AutoNetwork {
|
|
|
|
// f.network is overloaded to support a concept of 'automatic' addresses,
|
|
|
|
// which signals that the gopls remote address should be automatically
|
|
|
|
// derived.
|
|
|
|
// So we need to resolve a real network and address here.
|
|
|
|
network, address = autoNetworkAddress(f.goplsPath, f.addr)
|
|
|
|
}
|
|
|
|
// Try dialing our remote once, in case it is already running.
|
|
|
|
netConn, err = net.DialTimeout(network, address, f.dialTimeout)
|
|
|
|
if err == nil {
|
|
|
|
return netConn, nil
|
|
|
|
}
|
|
|
|
// If our remote is on the 'auto' network, start it if it doesn't exist.
|
|
|
|
if f.network == AutoNetwork {
|
|
|
|
if f.goplsPath == "" {
|
|
|
|
return nil, fmt.Errorf("cannot auto-start remote: gopls path is unknown")
|
|
|
|
}
|
|
|
|
if network == "unix" {
|
|
|
|
// Sometimes the socketfile isn't properly cleaned up when gopls shuts
|
|
|
|
// down. Since we have already tried and failed to dial this address, it
|
|
|
|
// should *usually* be safe to remove the socket before binding to the
|
|
|
|
// address.
|
|
|
|
// TODO(rfindley): there is probably a race here if multiple gopls
|
|
|
|
// instances are simultaneously starting up.
|
|
|
|
if _, err := os.Stat(address); err == nil {
|
|
|
|
if err := os.Remove(address); err != nil {
|
|
|
|
return nil, fmt.Errorf("removing remote socket file: %v", err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if err := startRemote(f.goplsPath, network, address); err != nil {
|
|
|
|
return nil, fmt.Errorf("startRemote(%q, %q): %v", network, address, err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// It can take some time for the newly started server to bind to our address,
|
|
|
|
// so we retry for a bit.
|
|
|
|
for retry := 0; retry < f.retries; retry++ {
|
|
|
|
startDial := time.Now()
|
|
|
|
netConn, err = net.DialTimeout(network, address, f.dialTimeout)
|
|
|
|
if err == nil {
|
|
|
|
return netConn, nil
|
|
|
|
}
|
|
|
|
log.Print(ctx, fmt.Sprintf("failed attempt #%d to connect to remote: %v\n", retry+2, err))
|
|
|
|
// In case our failure was a fast-failure, ensure we wait at least
|
|
|
|
// f.dialTimeout before trying again.
|
|
|
|
if retry != f.retries-1 {
|
|
|
|
time.Sleep(f.dialTimeout - time.Since(startDial))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nil, fmt.Errorf("dialing remote: %v", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
func startRemote(goplsPath, network, address string) error {
|
|
|
|
args := []string{"serve", "-listen", fmt.Sprintf(`%s;%s`, network, address), "-debug", ":0", "-logfile", "auto"}
|
|
|
|
cmd := exec.Command(goplsPath, args...)
|
|
|
|
if err := cmd.Start(); err != nil {
|
|
|
|
return fmt.Errorf("starting remote gopls: %v", err)
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-02-09 12:44:03 -07:00
|
|
|
// ForwarderExitFunc is used to exit the forwarder process. It is mutable for
|
|
|
|
// testing purposes.
|
|
|
|
var ForwarderExitFunc = os.Exit
|
|
|
|
|
2020-02-19 08:18:21 -07:00
|
|
|
// OverrideExitFuncsForTest can be used from test code to prevent the test
|
|
|
|
// process from exiting on server shutdown. The returned func reverts the exit
|
|
|
|
// funcs to their previous state.
|
|
|
|
func OverrideExitFuncsForTest() func() {
|
|
|
|
// Override functions that would shut down the test process
|
|
|
|
cleanup := func(lspExit, forwarderExit func(code int)) func() {
|
|
|
|
return func() {
|
|
|
|
lsp.ServerExitFunc = lspExit
|
|
|
|
ForwarderExitFunc = forwarderExit
|
|
|
|
}
|
|
|
|
}(lsp.ServerExitFunc, ForwarderExitFunc)
|
|
|
|
// It is an error for a test to shutdown a server process.
|
|
|
|
lsp.ServerExitFunc = func(code int) {
|
|
|
|
panic(fmt.Sprintf("LSP server exited with code %d", code))
|
|
|
|
}
|
|
|
|
// We don't want our forwarders to exit, but it's OK if they would have.
|
|
|
|
ForwarderExitFunc = func(code int) {}
|
|
|
|
return cleanup
|
|
|
|
}
|
|
|
|
|
2020-02-09 12:44:03 -07:00
|
|
|
// forwarderHandler intercepts 'exit' messages to prevent the shared gopls
|
|
|
|
// instance from exiting. In the future it may also intercept 'shutdown' to
|
|
|
|
// provide more graceful shutdown of the client connection.
|
|
|
|
type forwarderHandler struct {
|
|
|
|
jsonrpc2.EmptyHandler
|
|
|
|
}
|
|
|
|
|
|
|
|
func (forwarderHandler) Deliver(ctx context.Context, r *jsonrpc2.Request, delivered bool) bool {
|
|
|
|
// TODO(golang.org/issues/34111): we should more gracefully disconnect here,
|
|
|
|
// once that process exists.
|
|
|
|
if r.Method == "exit" {
|
|
|
|
ForwarderExitFunc(0)
|
|
|
|
// Still return true here to prevent the message from being delivered: in
|
|
|
|
// tests, ForwarderExitFunc may be overridden to something that doesn't
|
|
|
|
// exit the process.
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
return false
|
|
|
|
}
|
2020-02-19 08:18:21 -07:00
|
|
|
|
|
|
|
type handshaker struct {
|
|
|
|
jsonrpc2.EmptyHandler
|
2020-02-18 10:47:19 -07:00
|
|
|
client *debugClient
|
|
|
|
debug *debug.Instance
|
|
|
|
goplsPath string
|
2020-02-19 08:18:21 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
type handshakeRequest struct {
|
|
|
|
ServerID string `json:"serverID"`
|
|
|
|
Logfile string `json:"logfile"`
|
|
|
|
DebugAddr string `json:"debugAddr"`
|
2020-02-18 10:47:19 -07:00
|
|
|
GoplsPath string `json:"goplsPath"`
|
2020-02-19 08:18:21 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
type handshakeResponse struct {
|
|
|
|
ClientID string `json:"clientID"`
|
|
|
|
SessionID string `json:"sessionID"`
|
|
|
|
Logfile string `json:"logfile"`
|
|
|
|
DebugAddr string `json:"debugAddr"`
|
2020-02-18 10:47:19 -07:00
|
|
|
GoplsPath string `json:"goplsPath"`
|
2020-02-19 08:18:21 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
const handshakeMethod = "gopls/handshake"
|
|
|
|
|
|
|
|
func (h *handshaker) Deliver(ctx context.Context, r *jsonrpc2.Request, delivered bool) bool {
|
|
|
|
if r.Method == handshakeMethod {
|
|
|
|
var req handshakeRequest
|
|
|
|
if err := json.Unmarshal(*r.Params, &req); err != nil {
|
|
|
|
sendError(ctx, r, err)
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
h.client.debugAddress = req.DebugAddr
|
|
|
|
h.client.logfile = req.Logfile
|
|
|
|
h.client.serverID = req.ServerID
|
2020-02-18 10:47:19 -07:00
|
|
|
h.client.goplsPath = req.GoplsPath
|
2020-02-19 08:18:21 -07:00
|
|
|
resp := handshakeResponse{
|
|
|
|
ClientID: h.client.id,
|
|
|
|
SessionID: cache.DebugSession{Session: h.client.session}.ID(),
|
|
|
|
Logfile: h.debug.Logfile,
|
2020-02-18 10:47:19 -07:00
|
|
|
DebugAddr: h.debug.ListenedDebugAddress,
|
|
|
|
GoplsPath: h.goplsPath,
|
2020-02-19 08:18:21 -07:00
|
|
|
}
|
|
|
|
if err := r.Reply(ctx, resp, nil); err != nil {
|
|
|
|
log.Error(ctx, "replying to handshake", err)
|
|
|
|
}
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
|
|
|
func sendError(ctx context.Context, req *jsonrpc2.Request, err error) {
|
|
|
|
if _, ok := err.(*jsonrpc2.Error); !ok {
|
|
|
|
err = jsonrpc2.NewErrorf(jsonrpc2.CodeParseError, "%v", err)
|
|
|
|
}
|
|
|
|
if err := req.Reply(ctx, nil, err); err != nil {
|
|
|
|
log.Error(ctx, "", err)
|
|
|
|
}
|
|
|
|
}
|