The utility of the debug server is limited by the requirement to start
gopls with the `-debug` flag and then look in the logs to see which port
the debug server is bound to.
This CL adds a new custom command `gopls.startDebugging` to start the
debug server on demand if it isn't already running, and return its debug
address. It also does some gymnastics to make this turn on debugging for
any intermediate gopls forwarders, when using daemon mode.
For golang/go#45518
Change-Id: I48a90088f96aca54f34f93bedbfe864515320f61
Reviewed-on: https://go-review.googlesource.com/c/tools/+/309409
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>
Locating the workspace module by convention has multiple problems:
+ gopls's view of $TMPDIR might be different from the client
+ there might be multiple views
+ there might be multiple gopls sessions per pid
Instead, assign a temp workspace directory for each workspace folder,
and provide a command to access this information.
Cleaning up all these temp directories was overcomplicated. Instead,
create a temp directory for the gopls server to nest them under, that
can be removed up on server shutdown.
Also fix a bug where the snapshot was not acquired before copying its
workspace.
Updates golang/go#42252
Change-Id: I0641cebe09cd376dfa27373cac30397711c64a8f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/300409
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>
Rather than using the directory of the package, store the package ID and
calculate the directory in GCOptimizationDetails. I think this is
slightly more readable/cleaner.
Change-Id: I13cac8a7552b73b2bd5d25ff582b5d4936a74827
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297877
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>
Previously, we were running `go get` only on modules, which led to us
not downloading dependencies of packages. This resulted in further
go.mod diagnostics that users could not resolve with quick fixes. Now,
download packages directly so that dependencies are downloaded.
Fixesgolang/go#44307
Change-Id: Id764ea5a2f7028e238eadaaba0ca3cfc765b85b4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293729
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
We currently write directly to go.mod/sum via the go command, expecting
that editors will pick up the changes. While that's true for VS Code,
vim doesn't necessarily reload unchanged buffers. Change to send
explicit edits instead, but only if the file is open. Behavior when
using Go versions that don't support -modfile is unchanged.
Fixesgolang/go#44035.
Change-Id: Ie4e5cf60673b860f5dfcbdb726bee0efe6aae405
Reviewed-on: https://go-review.googlesource.com/c/tools/+/290189
Trust: Heschi Kreinick <heschi@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Add the ListKnownPackages and AddImport methods to command.Interface and
regenerate bindings. Add empty implementations to lsp.commandHandler.
These are our first commands returning results. I'll update our docgen
to support result in a subsequent CL.
Change-Id: Ic3b7c0d9383ac8f3e1cb546a71e9c496a92a7840
Reviewed-on: https://go-review.googlesource.com/c/tools/+/291129
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
When go.sum updates are needed in experimental workspace module mode, we
don't necessarily know which module needs the correction. As a fix,
apply all of these fixes to each module in the multi-module workspace.
The "add dependency" quick fix also seems to be broken, but I'll fix
that in a separate CL.
Fixesgolang/go#44097
Change-Id: Id4a6013f2aceb6b902dff3118b027f6cb99eb3c1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/289772
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Smuggling the Context was too fancy, and unidiomatic.
Change-Id: Iabca39ed73d5a40bfe7d500358228700eefbc60f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/290790
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>
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>
appliesFn and suggestedFixFn were blocking eliminating the
source.Command dynamic configuration. Remove them, and along the way
refactor command dispatch to align better with the new
internal/lsp/command package.
This involved refactoring the internal/lsp/command.go as follows:
- create a new commandHandler type, which will eventually implement
command.Interface.
- create a commandDeps struct to hold command dependencies.
- move command functionality into methods on commandHandler.
Of these, there are likely to be at least a couple points of controvery:
I decided to store the ctx on the commandHandler, because I preferred it
to threading a context through command.Interface when it isn't needed.
We should revisit this in a later CL.
I opted for a sparse commandDeps struct, rather than either explicit
resolution of dependencies where necessary, or something more abstract
like a proper dependency resolution pattern. It saved enough boilerplate
that I deemed it worthwhile, but didn't want to commit to something more
sophisticated.
Actually switching to the internal/lsp/command package will happen in a
later CL.
Change-Id: I71502fc68f51f1b296bc529ee2885f7547145e92
Reviewed-on: https://go-review.googlesource.com/c/tools/+/289970
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>
Create the 'prepareAndRun' helper to offload some common command set-up
within the command handler. In subsequent CLs, this will be used to hold
all configuration of the implementation, including whether the command
will execute asynchronously, and whether to show progress.
Change-Id: I6d0f072e805dade5c7df37fa5cdf993d397fa717
Reviewed-on: https://go-review.googlesource.com/c/tools/+/288494
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The only thing that the mod tidy diagnostics use the network for is
adding dependencies, and we already have quick fixes for those. The one
exception is the case covered by TestBadlyVersionedModule, a dependency
that fails to declare one of its own dependencies and therefore requires
an indirect dependency in the workspace module. That only triggers an
error on the dependency's import statement, which the user will never
see.
Fortunately, the go command does expose these problems in the DepsErrors
field of the list response. Add an internal API to access that, and turn
it into diagnostics on both the file and the controlling go.mod.
Refactor the go get diagnostic generation so that it applies to both
modules and packages.
Fixesgolang/go#38462.
Change-Id: Ie2af940087654682a40de9ecfccd46f404a88b60
Reviewed-on: https://go-review.googlesource.com/c/tools/+/289309
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>
source.Error and source.Diagnostic are almost identical types, used
arbitrarily in different parts of the code. This CL is the first step in
cleaning up that redundancy: it deletes the source.Error type.
To do that, I added the fields from source.Error to source.Diagnostic,
and made absolutely no other semantic code changes -- I just renamed
things that were named Error to Diagnostic. With only aesthetic concerns
in play, I hope this CL will be easy to review. The next CL will clean
up all the stupid-looking code that converts a Diagnostic to a
Diagnostic, etc.
Change-Id: I1298cc8144c686b8a37fc2cc106930105e511353
Reviewed-on: https://go-review.googlesource.com/c/tools/+/288214
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
The Typescript source is still at version 3.16, but there are new
requests, more detailed client capabilities, and an attempt to be
more specific about ranges of number in the Typescript code.
Vscode defines types integer and uinteger (32-bit signed and unsigned),
so the Go code now uses int32 and uint32.
They've changed the use of TextDocument, so version information is sometimes
missing. cache/session.go:625 was changed correspondingly.
This CL also make CodeAction.Disabled into a pointer.
New requests or notifications:
DidCreateFiles, DidRenameFiles, DidDeleteFiles (notifications)
ShowDocument, WillCreateFiles,WillRenameFiles, WillDeleteFiles (request)
It's a lot of code; I've probably missed something.
Change-Id: I8449ad8473ac00947d0344c5f6133f9bd73b9e10
Reviewed-on: https://go-review.googlesource.com/c/tools/+/286192
Run-TryBot: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Peter Weinberger <pjw@google.com>
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>
golang/go#43335 explains the issues with using `go get module@none`,
which will only be resolved in Go 1.17. In the meantime, we use the
go command whenever possible, but if the module is not tidied, we
have to use textual edits instead. This means the go.sum file will not
be accurately updated to remove the dependency, but unfortunately, I
don't believe there is anything that we can do in that case.
Fixesgolang/go#43335
Change-Id: I771f68f34a6136e73e9dd82b692ed4c235c3b293
Reviewed-on: https://go-review.googlesource.com/c/tools/+/279716
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Executing the "go test" command did pass Package.PkgPath() as first
argument to the go invokation before. That failed when using test
packages with _test suffix.
The "go test" command now use Package.ForTest() instead.
Fixesgolang/go#43037
Change-Id: Iea1a0e0c949a53770c1d3e1126a16a9c4952a53f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275496
Trust: Pontus Leitzler <leitzler@gmail.com>
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
With -mod=readonly set, we no longer automatically add new requires to
go.mod, even the temporary one. We have the go mod tidy code lens, but
that only works on saved files, even in 1.16 due to golang/go#42491.
Plus we may remove the code lens's network access in the future.
Add a simple quick fix for import errors that runs (the moral equivalent
of) go get on the missing import.
Change-Id: Id5764a37ce7db0dce5370da9d648462aefa2042b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274121
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>
Reviewed-by: Robert Findley <rfindley@google.com>
For users with poor network connections, go command invocations that
access the network may hang up for long periods of time. Even for
users with good network connections, accessing proxy.golang.org or
github can take a few seconds, which is a long time to lock up an
editor.
Disable network access via GOPROXY=off when running most go commands.
There are two notable exceptions. First, the initial workspace load is
allowed, though subsequent loads are not. My reasoning is that if the
user is opening a project they've just downloaded, they probably expect
to fetch its dependencies. (Also, it's convenient to keep the regtests
going.) The second is the go mod tidy diagnostics, which I hope to
address in a later change. All the other commands that access the
network are at the user's request.
When the workspace load fails due to a dependency that hasn't been
downloaded, we present a quick fix on the go.mod line to do so. The only
way that happens is if there's a manual modification to the go.mod file,
since all of the other quick fixes will do the download. So I don't
think there's a need to present the fix anywhere else.
Updates golang/go#38462.
Change-Id: I470bc1ba790db7c1afee54d0b28fa0c6fd203fb9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274120
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>
Reviewed-by: Robert Findley <rfindley@google.com>
Go 1.16 will set -mod=readonly to be the default behavior of the go
command. This CL changes gopls' behavior to be more in line with that.
The model we end up with is more explicit about managing the go.mod.
Previously, adding an import for a package in the module cache but not
in scope would succeed, but add a warning with a quick fix. Now, the
import will fail, again with a quick fix, and the project will not
compile until the require is added. It also means that the go.sum needs
to be in sync. Previously, the go command would update the temporary
go.sum if the user's was out of date, and then we would discard those
changes. Now, loads will fail until the go.sum is brought into sync,
either by `go mod tidy` or the new "update go.sum" command.
The go.sum requirements affect many regtests. I added a DumpGoSum
function to the environment, which prints the txtar format go.sum file
that needs to be added to the workspace. We'll need to keep them in
sync, unfortunately. We could update them on the fly, but that would
slow down the regression tests somewhat and potentially mess up the test
setup. So I'm not sure what to do exactly. Perhaps maintain them
out-of-line in a separate file that could be auto-updated? Dunno.
I also had to add go directives to go.mod files to keep old Go versions
happy.
Multi-module workspace mode currently doesn't create a go.sum file at
all and is held back to the old behavior until it does.
Change-Id: Ib31afc17614afac2f5fbdf31c7fc03a90bd13e3a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/268597
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>
Our handling of diagnostics has gotten complicated and has recently been
a source of bugs. Heschi and I took a step back and refactored the
diagnostic pass, starting with a new data structure for tracking
diagnostics.
The LSP server now holds a map of URI to collection of diagnostic
reports, which is used to track diagnostics as they are computed by
multiple sources. Additionally, this collection holds a hash of the
last published diagnostic set.
This new information allows us to implement an algorithm for
incrementally updating diagnostics on the server: diagnostics reports
are stored as they are computed for a snapshot, and then published in
(possibly multiple) passes, with the last pass for a snapshot being
marked as 'final'. In non-final passes, 'publishReports' publishes any
diagnostics that have already been computed for the snapshot, but does
nothing with URIs for which no diagnostics have been computed. In final
passes all diagnostics are reported, with empty diagnostics being
published for any URIs with no diagnostic reports. Any URIs for which no
diagnostic reports were computed are pruned from the diagnostic set. In
all cases, tracking the hash of published diagnostics prevents us from
duplicate publication.
This enables some simplifications of the existing diagnostic logic.
Computing new diagnostics and tracking send diagnostics is now handled
by the same algorithm, avoiding some bookkeeping. It is also no longer
necessary to explicitly clear diagnostics for deletions. This fixes some
previously broken edge cases, for example when packages go out of scope
due to go.mod or gopls.mod changes.
Fixesgolang/go#42198
Change-Id: Id0d8d0f7a60f6ffa8c33f0ae41763461f61dab7b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/269677
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>
Trust: Robert Findley <rfindley@google.com>
We both showing errors as a popup and returning them to the client,
which would then most likely show them as a popup. Don't return errors
back to the client.
Change-Id: I8486534e19399d514752900025d6db8db85d5086
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272090
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>
In CL 256941 I suggested using `go generate ...` to run all the
generates in the current directory and its subdirectories. That was
wrong: ... means all in-scope packages. The correct pattern is ./... .
Change-Id: I1cb4e6b7cfbcd9b8f943d7193e4aee216614cdff
Reviewed-on: https://go-review.googlesource.com/c/tools/+/269318
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
The "go test" command invoked via code action/code lens performs a
ShowMessage callback to the client when the test is done.
Previously it did set severity to "Error" when the test failed, but a
failing test isn't a error condition per se. This changes the result to
be of severity Info for both successful and failed test invocations.
Change-Id: Ib76558d98a434c706823617b9901a88e53864319
Reviewed-on: https://go-review.googlesource.com/c/tools/+/269257
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
This fixes an issue where we were reloading packages in the vendor
directory when they changed on-disk. We should only do this if the
packages are part of the workspace or the files are opened.
Change-Id: Iefbd690ec0c096d9a40c62ce567c18335024ea15
Reviewed-on: https://go-review.googlesource.com/c/tools/+/268038
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When adding a require, we should add an `// indirect` comment if that's
what go mod tidy would do.
It's possible I should split Add out from Update and Remove, but this
was quick and easy and I'm not too worried about it for now.
Also minimize the test that covered this case, which was way more
complicated than it needed to be AFAICT.
Fixesgolang/go#38914.
Change-Id: I89c44f8573873227c4c9e637d1d31d8c1a6530aa
Reviewed-on: https://go-review.googlesource.com/c/tools/+/267578
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>
This CL uses the approach of a source.ErrorList for the `go mod vendor`
error--rather than a ShowMessageRequest. The suggested fix is a command
that runs `go mod vendor`, so I added a CommandFix to the source.Error
type.
I'm not sure if a diagnostic is better than a ShowMessageRequest--
perhaps it should be both?
Fixesgolang/go#41819Fixesgolang/go#42152
Change-Id: I4ba2d7af0233f13583395e871166caed83454d6e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/261737
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When incorporating the gopls.mod file, the invalidation logic for
workspace module information becomes quite complicated. For example:
+ if a modfile changes we should only invalidate if it is in the set of
active modules
+ the set of active modules can be provided by either the filesystem or
gopls.mod
+ if gopls.mod changes, we may gain or lose active modules in the
workspace
+ if gopls.mod is *deleted*, we may need to walk the filesystem to
actually find all active modules
Doing this with only concrete changes to the snapshot proved
prohibitively complex (at least for me), so a new workspace type is
introduced to manage the module state. This new abstraction is
responsible for tracking the set of active modules, the workspace
modfile, and the set of workspace directories. Its invalidation logic is
factored out of snapshot.clone, so that it can be tested and to
alleviate some of the growing complexity of snapshot.clone.
The workspace type is idempotent, allowing it to be shared across
snapshots without needing to use the cache. There is little benefit to
the cache in this case, since workspace module computation should be
infrequent, and the type itself consumes little memory.
This is made possible because the workspace type itself depends only on
file state, and therefore may be invalidated independently of the
snapshot. The new source.FileState interface is used in testing, and so
that the workspace module may be computed based on both the session file
state as well as the snapshot file state.
As a result of this change, the following improvements in functionality
are possible:
+ in the presence of a gopls.mod file, we avoid walking the filesystem
to detect modules. This could be helpful for working in large
monorepos or in GOPATH, when discovering all modules would be
expensive.
+ The set of active modules should always be consistent with the
gopls.mod file, likely fixing some bugs (for example, computing
diagnostics for modfiles that shouldn't be loaded)
For golang/go#41837
Change-Id: I2da888c097748b659ee892ca2d6b3fbe29c1942e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/261237
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>
Trust: Robert Findley <rfindley@google.com>
Modifying go.mod files directly leaves go.sum unchanged, and therefore
in need of updates later. Leaving work for the users to clean up isn't
ideal, so it'd be better to use the go command to make modifications.
Unfortunately, the go command has something of a mind of its own. The
most obvious problem is that using go get to add a new require adds a
// indirect comment to that new require, and there's no way to prevent
it. The only thing we can do is add the require first, then use go get
to do nothing but update the go.sum file.
The other inherent problem is that the go command operates on files as
they exist on disk, not the in-memory versions. As discussed, we issue
an error for this case. The alternative would be to work on temporary
files based on the in-memory contents, but that would be much larger
change, so I'd rather not at least right now.
To support Commands for quick fixes, add a new Command field to
source.SuggestedFix, and use it when forming the CodeAction response.
Fixesgolang/go#38209.
Change-Id: I0c13ea39199368623e7494e222ba38587323d417
Reviewed-on: https://go-review.googlesource.com/c/tools/+/265981
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>
We have two parallel code paths for Load and other go command
invocations. Unify them by introducing a mode argument to the various
functions that run the go command, indicating the purpose of the
invocation. That purpose can be used to infer what features should be
enabled.
In the future, I hope we can use the mode to decide whether mod
file updates and network access should be allowed.
Change-Id: I49c67fcefc9141287b78c56e9812ee6a8ac8378a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/265238
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>
We pass around verb/args/wd in many places. Bundle them up as an
Invocation instead. goCommandInvocation now updates and returns an input
Invocation.
packages.Config is conceptually an extra layer of parsing and
type-checking on top of a go list invocation. It doesn't make sense for
us to construct the latter using the former. A later CL will construct
the Config in terms of the Invocation; for now duplicate a bit of logic.
Use the environment in the cache key for various module operations
rather than the Config hash. I'm not sure either is fully correct but I
think the environment captures everything that's likely to matter. This
way we don't need Configs in those functions at all.
Change-Id: Iebee2705e63638ab365b3ee18b23f8c3e8ca30ce
Reviewed-on: https://go-review.googlesource.com/c/tools/+/265237
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>
This makes all commands with the exception of running tests synchronous.
Remove the special handling for applying suggested fixes. Instead, make
workDone reporting a no-op if the workDone handle is nil.
Change-Id: I6801c91f8564d68b8bdaaf9456cd6752b164d0b9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/265583
Run-TryBot: Robert Findley <rfindley@google.com>
Trust: 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>
Synchronous commands were bypassing the logic to handle the command
error an publish a final workDoneProgressEnd message. Push this logic
down into Server.runCommand.
Also, switch 'generate' to be synchronous, since this makes sense and
causes the synchronous path to be exercised in tests.
Finally, stop defaulting the command title to Command.Name. All Commands
should have Titles.
Change-Id: Id0b1e5283e54d82c307e933782317372bd8971af
Reviewed-on: https://go-review.googlesource.com/c/tools/+/265737
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
The primary identifier for gopls commands was changed from Command.Name
to Command.ID(), but this change was not made in the commands passed
back to the client via ExecuteCommandOptions.
Fix this, and ensure that our regtests actually check commands against
the list of supported commands that has been sent.
For golang/go#41985
Change-Id: If566584f157e8a86d26eac6353dbfd772b298cfc
Reviewed-on: https://go-review.googlesource.com/c/tools/+/262597
Run-TryBot: Robert Findley <rfindley@google.com>
Trust: 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>
Updated the generator to check for this. Necessary to fix command name
collision in VS Code Go. Not the nicest solution, but seemed like the
least invasive one.
The codelens configuration is a little strange now, with the "gopls_"
prefixes, but the alternative is adding the prefix when processing the
config and that would make the default look different from the example.
Fixesgolang/go#41187
Change-Id: I5cf42f4a96f6252016dcd5c40a4ac401e1b30a8f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/259204
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
An experimental new feature is added to run parsing and checking on
modified files immediately, and run analysis and diagnostics for
transitive dependencies only after debouncing. This feature is disabled
by default.
Also, some refactoring is done along the way:
+ Clean up diagnostic functions a bit using a report collection type.
+ Factor out parsing diagnostics in options.go.
Change-Id: I2f14f9e30d79153cb4219207de3d9e77e1f8415b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/255778
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>
Trust: Robert Findley <rfindley@google.com>
Splitting this CL out of CL 257417 to minimize the number of changes.
A few of the view's methods are moved to the snapshot, as they will
soon rely on the snapshot's modules field. Some dead code is also
deleted.
We now populate the snapshot's modules field even when
ExperimentalWorkspaceModule is not true, but we stop looking for modules
after searching the view's root.
Change-Id: Id0068ec10fafcfa6f7694dfcb8aaee8cb025078f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/257961
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This change allows a view to have multiple go.mod files associated
with it. This doesn't actually make any changes in internal/lsp/cache
with regards to the view's modURI, but it does do the necessary plumbing
in the client packages.
The next CL will delete modURI.
Updates golang/go#32394
Change-Id: I2312efd69c364aed4244ee3769679885a1ebc7e4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/256941
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This change adds a test to check the functionality of the GC details
code lens, including the behavior of toggling it on and off. This
exposed a Windows bug that was mentioned on Slack, which can be fixed by
adjusting the URI.
I also refactored a bit of the code to use a JSON decoder, which
simplifies things a little bit.
Change-Id: I7737107cf020fa35bca245485a3b1a1416920fd2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/256940
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
The go generate command was not honoring its dir argument, instead just
running in the workspace root.
Fixesgolang/go#41566
Change-Id: I5fb96a765cf4fb2572e2a8a2e560e02f0760023f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/256818
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>
Wire up a command to generate a gopls.mod file for a multi-module
workspace. In the future, this can actually be used to manage the
workspace, but for now the file is just generated, not actually used.
For golang/go#32394
Change-Id: I8a53da8ac9337bde132c7d8ca8557467f368fc24
Reviewed-on: https://go-review.googlesource.com/c/tools/+/256042
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Some failure modes for suggested fixes were not displaying a failure
message. Refactor so that all errors result in a message.
Fixesgolang/go#41413
Change-Id: I939d707626c2bd93c19e28f2197f4f1c66c6947c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/255128
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This is better than parsing the default output.
Also, change the start progress message, since it ends up duplicating
the title in the message that the user sees.
Change-Id: I3540d30c7976c6be0722531b2e258341081e0b72
Reviewed-on: https://go-review.googlesource.com/c/tools/+/251920
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This change contains several improvements for progress reporting:
+ Consolidate the 'progressWriter' interface into the workDone
interface. Now all progress reporting should use workDone, and the
workDoneWriter struct is just an io.Writer adapter on top of
workDone.
+ Factor out the pattern of progress reporting, and use for all
asynchronous commands.
+ Make several commands that were previously synchronous async.
+ Add a test for cancellation when the WorkDone API is not supported.
+ Always report workdone progress using a detached context.
+ Update 'run tests' to use the -v option, and merge stderr and stdout,
to increase the amount of information reported.
+ Since $/progress reporting is now always run with a detached context,
the 'NoOutstandingWork' expectation should now behave correctly. Use
it in a few places.
A follow-up CL will improve the messages reported on command completion.
For golang/go#40634
Change-Id: I7401ae62f7ed22d76e558ccc046e981622a64b12
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248918
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
CL 248380 forced all type checking to be in the default workspace mode.
In that CL, I said I couldn't think of any features that would break. It
appears I didn't think very hard. Navigation features inside of
dependencies are something I use all the time and they broke.
Reintroduce the ability to get packages in a particular mode, and make
it convenient to get them in all relevant modes. Update some critical
features to do so, and add regression tests.
Fixesgolang/go#40809.
Change-Id: I96279f4ff994203694629ea872795246c410b206
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249120
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Some Commands require that the buffer is saved before running them (i.e.
generate, test and toggle details). If the buffer isn't saved gopls
sends a ShowMessage request to the client. Before this change it
did not return any error from the ExecuteCommand request itself (unless
ShowMessage failed).
A progress token can be provided by the client as a part of the
ExecuteCommand request, and that is, according to the LSP spec one way
to start a WorkDoneProgress. At this point the client expects
that gopls send progress updates.
With this change, ExecuteCommand now return an error if the buffer
isn't saved, so that the client know that it shouldn't expect any
progress updates with this specific token.
Change-Id: I8a7af20a0c1532fc4ad03efd4e04bfb1a6871644
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248766
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Rob Findley
Heschi Kreinick
Rebecca Stambler
pjw
Pontus Leitzler