Package loading (at least via go list) fails when the import header
doesn't parse, so we need to invalidate metadata upon a state change
from non parsing->parsing. Refactor metadata invalidation to implement
this feature, add additional documentation, and avoid unnecessary work.
This change revealed a latent bug (via TestDeleteDirectory): when
statting a deleted directory failed, we could fail to invalidate any
package IDs, even those we already knew about. This bug was masked by
the somewhat complicated semantics of pkgNameChanged. The semantics of
pkgNameChanged are simplified to encapsulate any change to a
package->file association.
Also refactor the parsing API somewhat, and add a bug report if we don't
get a ParseGoFile while inspecting for metadata changes.
Update most regtests to panic upon receiving bug reports.
Fixesgolang/go#52981
Change-Id: I1838963ecc9c01e316f887aa9d8f1260662281ab
Reviewed-on: https://go-review.googlesource.com/c/tools/+/407501
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
We care that gopls operations complete within a reasonable time.
However, what is “reasonable” depends strongly on the specifics of the
user and the hardware they are running on: a timeout that would be
perfectly reasonable on a high-powered user workstation with little
other load may be far too short on an overloaded and/or underpowered
CI builder.
This change adjusts the regtest runner to use the test deadline
instead of an arbitrary, flag-defined timeout; we expect the user or
system running the test to scale the test timeout appropriately to the
specific platform and system load.
When the testing package gains support for per-test timeouts
(golang/go#48157), this approach will automatically apply those
timeouts too.
If we decide that we also want to test specific performance and/or
latency targets, we can set up specific configurations for that (as
either aggressive per-test timeouts or benchmarks) in a followup
change.
For golang/go#50582
Change-Id: I1ab11b2049effb097aa620046fe11609269f91c4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/380497
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
We may want to generalize this to have regtest.Run always derive the
default timeout from the test's deadline. In the meantime, this is a
more targeted fix for the specific timeout in TestGCDetails.
Fixesgolang/go#49902
(Maybe.)
Change-Id: Ie15735dc7b0d462ec047d3f3d8a2eceeb4411fa0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/380496
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Because of how the compiler internally represents variable references,
it sometimes gets position information incorrectly for them. The
codelens test hits this issue because for
var x string
fmt.Println(x)
the diagnostic about "x" escaping to heap (which actually refers to
the implicit conversion to "interface{}" type) should be rightly
reported at the "x" identifier within the call arguments list.
However, due to the aforementioned compiler bug, historically we
reported the diagnostic at the "(" token instead.
In -G=3 mode, the compiler (correctly) report the diagnostic at "x"
instead; but with GOEXPERIMENT=unified, the compiler intentionally
matches the original -G=0 behavior and continues reporting at "("
instead.
This CL avoids the issue entirely by changing the line to
"fmt.Println(42)", which avoids the issue because the compiler always
correctly prints the diagnostic then at "42".
Change-Id: I22d4c756ae801489f3f16c440e4339bc9b115fb0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/343875
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
When setting metadata, we must invalidate any packages that have been
computed with old metadata.
Also make setMetadata atomic, by locking around it in Load. This is just
writing memory after a Load, so should be fast and infrequent. It is
critical that our various maps related to metadata are coherent, so it
makes sense to err on the side of coarser locking, IMO.
Fix a race in TestUpgradeCodeLens.
Change-Id: Iee8003b7e52b9f21681bdba08a009824f4ac6268
Reviewed-on: https://go-review.googlesource.com/c/tools/+/331809
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
With the new ParseExported logic, we can lose some unexported fields on
exported structs. This can lead to misleading or malformatted hover
information.
Fix this by ensuring we always extract the Spec from a full parse. Since
this path is only hit via user-initiated requests (and should only be
hit ~once per request), it is preferable to do the parse on-demand
rather than parse via the cache and risk pinning the full AST for the
remaining duration of the session.
For golang/go#46158
Change-Id: Ib3eb61c3f75e16199eb492e3e129ba875bd8553e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/320550
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Note: this only moves the regtest framework, not the gopls regtest
tests.
Change-Id: Ia70d2e97df8a8bd48a042e5b037c1e56a210b594
Reviewed-on: https://go-review.googlesource.com/c/tools/+/312412
Trust: Paul Jolly <paul@myitcv.org.uk>
Run-TryBot: Paul Jolly <paul@myitcv.org.uk>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
My hope is that CL 304169 resolved this flake, but we'll have to see.
For golang/go#44099
Change-Id: Iac82dc24167daacd0361eac1a5567048a7ecf11c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/305409
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
In typeCheckDiagnostics, we have logic to suppress go list and type
checking errors based on the presence of other errors. Nobody seems to
know why the logic is exactly what it is, and suppressing list errors
means that bad //go:embed patterns don't show up.
Intuitively, it makes sense to me that we don't want to type check if
listing or parsing fails: list errors mean that whole files may be
missing, and parsing errors may wipe out arbitrary chunks of files.
There's little point reporting errors from type checking that. However,
list errors and parse errors should be mostly orthogonal: go list
parses very little of the file and in practice only reports errors
parsing the package statement. So, at least for now, we report both
parse and list errors, and stop there if there are any.
Finally, move the suppression logic to the actual typeCheck function
that generates the diagnostics. typeCheckDiagnostics is the primary
consumer, but I think it's better to do the suppression at the source.
Because we are now showing list errors, and they are prone to getting
stuck due to bad overlay support, a couple of tests now require 1.16.
Change-Id: I7801e44c4d3da30bda61e0c1710a2f52de6215f5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/295414
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This test is flaking at a relatively high rate on darwin and freebsd.
Skipping it is better than having a build dashboard with many known
failures.
Perhaps we could limit this skip to certain GOOS, but for now let's skip
it entirely until we understand the problem better.
For golang/go#44099
Change-Id: I58703b2db0e5768f75758080d07f9d29b8b5d661
Reviewed-on: https://go-review.googlesource.com/c/tools/+/291232
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Fully switch to the new generated command API, and remove the old
dynamic command configuration.
This involved several steps:
+ Switch the command dispatch in internal/lsp/command.go to go through
the command package. This means that all commands must now use the new
signature.
+ Update commandHandler to use the new command signatures.
+ Fix some errors discovered in the command interface now that we're
actually using it.
+ Regenerate bindings.
+ Update all code lens and suggested fixes to new the new command
constructors.
+ Generate values in the command package to hold command names and the
full set of commands, so that they may be referenced by name.
+ Update any references to command names to use the command package.
+ Delete command metadata from the source package. Rename command.go to
fix.go.
+ Update lsp tests to execute commands directly rather than use an
internal API. This involved a bit of hackery to collect the edits.
+ Update document generation to use command metadata. Documenting the
arguments is left to a later CL.
+ Various small fixes related to the above.
This change is intended to be invisible to users. We have changed the
command signatures, but have not (previously) committed to backwards
compatibility for commands. Notably, the gopls.test and gopls.gc_details
signatures are preserved, as these are the two cases where we are aware
of LSP clients calling them directly, not from a code lens or
diagnostic.
For golang/go#40438
Change-Id: Ie1b92c95d6ce7e2fc25fc029d1f85b942f40e851
Reviewed-on: https://go-review.googlesource.com/c/tools/+/290111
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Experiment with increasing the timeout for TestGCDetails, given how its
flakiness correlates with slow builders.
For golang/go#44099
Change-Id: I27a8732256a77c3d9ce2a1b1f75ce5d0fbc11e67
Reviewed-on: https://go-review.googlesource.com/c/tools/+/289690
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
In CL 271297, I disabled the constantly-running upgrade check, which
removed the upgrade commands for individual dependencies. This seems to
have been a relatively popular feature. Re-introduce it, but requiring
explicit user interaction.
We now run an upgrade check when the user clicks "Check for upgrades".
Those results are stored on the View and used to show diagnostics on
any requires they apply to. Right now we only check the go.mod the user
has open; in multi-module workspaces it might make sense to check all of
them, but I'm not sure.
Fixesgolang/go#42969.
Change-Id: I65205dc99a4fa9daafdb83145b0294b6f3be5336
Reviewed-on: https://go-review.googlesource.com/c/tools/+/286474
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Regtests have gotten large, and started timing out on some slow
builders. They also can't yet be run in parallel, due to some
process-level shared state (e.g. gc_details). Furthermore, there seems
to be some per-process resource leak that we don't yet fully understand
causing slowdown as the tests progress.
Address these problems by splitting the regtests up into multiple
packages. This also makes it easier to run only relevant tests during
development.
For golang/go#42789
For golang/go#39384
Change-Id: I1a74e4c379f3a650f4c434db44f9368e527aa459
Reviewed-on: https://go-review.googlesource.com/c/tools/+/287572
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Robert Findley
Bryan C. Mills
Matthew Dempsky
Heschi Kreinick
Paul Jolly