1
0
mirror of https://github.com/golang/go synced 2024-10-01 12:48:33 -06:00
go/internal/jsonrpc2/servertest/servertest.go

127 lines
3.3 KiB
Go
Raw Normal View History

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 servertest provides utilities for running tests against a remote LSP
// server.
package servertest
import (
"context"
"fmt"
"io"
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
"net"
"sync"
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"
)
// Connector is the interface used to connect to a server.
type Connector interface {
Connect(context.Context) *jsonrpc2.Conn
}
// TCPServer is a helper for executing tests against a remote jsonrpc2
// connection. Once initialized, its Addr field may be used to connect a
// jsonrpc2 client.
type TCPServer struct {
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
Addr string
ln net.Listener
cls *closerList
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
}
// NewTCPServer returns a new test server listening on local tcp port and
// serving incoming jsonrpc2 streams using the provided stream server. It
// panics on any error.
func NewTCPServer(ctx context.Context, server jsonrpc2.StreamServer) *TCPServer {
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
ln, err := net.Listen("tcp", "127.0.0.1:0")
if err != nil {
panic(fmt.Sprintf("servertest: failed to listen: %v", err))
}
go jsonrpc2.Serve(ctx, ln, server)
return &TCPServer{Addr: ln.Addr().String(), ln: ln, cls: &closerList{}}
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
}
// Connect dials the test server and returns a jsonrpc2 Connection that is
// ready for use.
func (s *TCPServer) Connect(ctx context.Context) *jsonrpc2.Conn {
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
netConn, err := net.Dial("tcp", s.Addr)
if err != nil {
panic(fmt.Sprintf("servertest: failed to connect to test instance: %v", err))
}
s.cls.add(func() {
netConn.Close()
})
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(jsonrpc2.NewHeaderStream(netConn, netConn))
go conn.Run(ctx)
return conn
}
// Close closes all connected pipes.
func (s *TCPServer) Close() error {
s.cls.closeAll()
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 nil
}
// PipeServer is a test server that handles connections over io.Pipes.
type PipeServer struct {
server jsonrpc2.StreamServer
cls *closerList
}
// NewPipeServer returns a test server that can be connected to via io.Pipes.
func NewPipeServer(ctx context.Context, server jsonrpc2.StreamServer) *PipeServer {
return &PipeServer{server: server, cls: &closerList{}}
}
// Connect creates new io.Pipes and binds them to the underlying StreamServer.
func (s *PipeServer) Connect(ctx context.Context) *jsonrpc2.Conn {
// Pipes connect like this:
// Client🡒(sWriter)🡒(sReader)🡒Server
// 🡔(cReader)🡐(cWriter)🡗
sReader, sWriter := io.Pipe()
cReader, cWriter := io.Pipe()
s.cls.add(func() {
sReader.Close()
sWriter.Close()
cReader.Close()
cWriter.Close()
})
serverStream := jsonrpc2.NewStream(sReader, cWriter)
go s.server.ServeStream(ctx, serverStream)
clientStream := jsonrpc2.NewStream(cReader, sWriter)
clientConn := jsonrpc2.NewConn(clientStream)
go clientConn.Run(ctx)
return clientConn
}
// Close closes all connected pipes.
func (s *PipeServer) Close() error {
s.cls.closeAll()
return nil
}
// closerList tracks closers to run when a testserver is closed. This is a
// convenience, so that callers don't have to worry about closing each
// connection.
type closerList struct {
mu sync.Mutex
closers []func()
}
func (l *closerList) add(closer func()) {
l.mu.Lock()
defer l.mu.Unlock()
l.closers = append(l.closers, closer)
}
func (l *closerList) closeAll() {
l.mu.Lock()
defer l.mu.Unlock()
for _, closer := range l.closers {
closer()
}
}