1
0
mirror of https://github.com/golang/go synced 2024-10-01 05:28:33 -06:00
Commit Graph

7 Commits

Author SHA1 Message Date
Rob Findley
912958979a internal/lsp/regtest: put testing.T back in the test func signature
In https://golang.org/cl/225157, I removed the redundant T and Context
parameters from the regtest func signature in an effort to reduce
confusion. In hindsight, removing the testing.T did not reduce
confusion, because there is a T in the test signature anyway (and now
it's the wrong T!).

Change-Id: I2e84009e9cb33cd51055012cfef9fe4987e1b9bd
Reviewed-on: https://go-review.googlesource.com/c/tools/+/228229
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Paul Jolly <paul@myitcv.org.uk>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-04-14 18:42:46 +00:00
Rob Findley
8cb32c4661 internal/lsp/regtest: clean up module names and include github issues
A couple small improvements for regtests:
 - module names fixed to include a '.'. This was fixed for diagnostic
   tests already.
 - For regtests that were written to exercise specifig github issues,
   include the issue number in the test name.

Change-Id: I67da6d78dc166e854d2543cf63dac382202f9dbc
Reviewed-on: https://go-review.googlesource.com/c/tools/+/226844
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-04-02 21:48:35 +00:00
Rob Findley
1fc30e1f4c internal/lsp/regtest: remove redundant T and ctx params from regtest funcs
In an effort to be idiomatic, I made the regtest func signature
func(context.Context, testing.T, *Env), despite the fact that Env
already has a Context and a T.

This just ended up causing more confusion, as it's not clear which
Context or T to use. Remove this and just use the fields on Env.

Change-Id: I54da1fdfe6ce17a67601b2af8640d4d2ea676e8c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/225157
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-03-24 20:18:24 +00:00
Rob Findley
4c83a7e07a internal/lsp/fake: add regexp search and replace
Expressing regtests in terms of textual coordinates is hard to read: the
reader ends up counting lines and characters to understand the text edit
or assertion.

To address, this, add two new functions for fake.Editor: RegexpSearch
and RegexpReplace, as well as a symmetric RegexpSearch function for
workspace files and wrappers for regtext.Env.

This allows expressing edits as well as buffer locations in terms of
easily scannable regexps.

An alternative solution to this problem is to integrate markers ala
packagestest. I tried this, but it ended up being cumbersome to
implement and less usable than regexps, due to the static nature of
markers: after the buffer has been edited all markers must be
updated.

Updates golang/go#36879

Change-Id: Iad087cf0d529737034197beef7b729816a159c69
Reviewed-on: https://go-review.googlesource.com/c/tools/+/224757
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-03-24 20:17:55 +00:00
Rob Findley
afe1c6fc1b internal/lsp/regtest: remove calls to t.Parallel()
Originally I decided to use t.Parallel() in hopes of uncovering new
bugs. That may have worked... but manifested as rare flakes that are
difficult to diagnose (golang.org/issues/37318).

Since this level of parallelism is extremely unlikely in normal gopls
workloads, I'm going to remove the t.Parallel() calls in hopes of
eliminating this flakiness. I'd rather be able to continue running these
tests.

Also, don't run in the 'Shared' execution mode by default: normal gopls
execution is either as a sidecar (the Singleton execution mode), or as a
daemon (the Forwarded execution mode).

Un-skip the TestGoToStdlibDefinition test, as hopefully it will no
longer flake.

Updates golang/go#37318.

Change-Id: Id73ee3c8702ab4ab1d039baa038fbce879e38df8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/221379
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-02-27 18:46:34 +00:00
Rob Findley
fe62aff319 internal/lsp/regtest: skip flaky TestGoToStdlibDefinition
This test is flaking on the Trybots. Skip it until this is understood.

Updates golang/go#37318

Change-Id: Ie4c1db47797b88d5eb201a73c4ddfb5481f362ea
Reviewed-on: https://go-review.googlesource.com/c/tools/+/220360
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Rohan Challa <rohan@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-02-21 15:21:58 +00:00
Rob Findley
0fd2d649e6 internal/lsp/lsprpc: add an LSP forwarder and regtest environment
Add a new Forwarder type to the lsprpc package, which implements the
jsonrpc2.StreamServer interface. This will be used to establish some
parity in the implementation of shared and singleton gopls servers.

Much more testing is needed, as is handling for the many edge cases
around forwarding the LSP, but since this is functionally equivalent to
TCP forwarding (and the -remote flag was already broken), I went ahead
and used the Forwarder to replace the forward method in the serve
command. This means that we can now use the combination of -listen and
-remote to chain together gopls servers... not that there's any reason
to do this.

Also, wrap the new regression tests with a focus on expressiveness when
testing the happy path, as well as parameterizing them so that they can
be run against different client/server execution environments. This
started to be sizable enough to warrant moving them to a separate
regtest package. The lsprpc package tests will instead focus on unit
testing the client-server binding logic.

Updates golang/go#36879
Updates golang/go#34111

Change-Id: Ib98131a58aabc69299845d2ecefceccfc1199574
Reviewed-on: https://go-review.googlesource.com/c/tools/+/218698
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-02-14 14:21:06 +00:00