This on average reduces latency from 25ms to 12ms on internal codebase.
Updates golang/go#45686
Change-Id: I49c8f09f8e54b7b486d7ff7eb8f4ba9f0d90b278
Reviewed-on: https://go-review.googlesource.com/c/tools/+/413655
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Add some additional logging to help debug golang/go#53586
For golang/go#53586
Change-Id: I0574fb01be47b265cd6e412855794bc2cb836dff
Reviewed-on: https://go-review.googlesource.com/c/tools/+/414854
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Findley <rfindley@google.com>
When setting new metadata for a package ID, we invalidate the
corresponding type-checked packages. Whenever we invalidate a package,
we must also invalidate its reverse transitive closure. Otherwise we may
end up in a scenario where the go/types import graph does not match
gopls' view of the import graph.
Change-Id: I8db6ff3e4a722656e6dde7907e7c0470375c4847
Reviewed-on: https://go-review.googlesource.com/c/tools/+/413683
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
If gopls believes it has valid metadata for a package, don't set new
metadata. This is consistent with previous behavior that was changed in
CL 340851.
In principle this shouldn't matter, but in practice there are places
where gopls doesn't yet want to invalidate packages, *even though* their
metadata may have changed (such as while editing a go.mod file before
saving). In the future we should eliminate these places, but for now we
should let snapshot.clone control this invalidation.
This also reduces the number of type-checked packages we invalidate on
load.
Change-Id: I0cc9bd4186245bec401332198de0047ff37e7ec7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/413681
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Previously, gopls would fall back on a gopath resolver when running
goimports from a directory containing go.work (but not go.mod). Fix this
by update the code to recognize that GOWORK also puts goimports into
module mode.
All the work to _support_ go.work had already been done, but the tests
were only passing because they were setting GO111MODULE=on explicitly
(and therefore GOMOD=/dev/null was satisfying the pre-existing check).
Also add a test for the regression in gopls.
Fixesgolang/go#52784
Change-Id: I31df6f71a949a5668e8dc001b3ee25ad26f2f927
Reviewed-on: https://go-review.googlesource.com/c/tools/+/413689
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
When using Go workspaces, the go.work file should be used to determine
which packages are workspace packages.
For golang/go#48929
Change-Id: I1a8753ab7887daf193e093fca5070b4cc250a245
Reviewed-on: https://go-review.googlesource.com/c/tools/+/400822
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
The Metadata type was mutated in exactly one place: when setting the
ShouldLoad bit after package loading completes. Address this by cloning
the metadata graph when clearing ShouldLoad. After this change, metadata
graphs and the data within them are immutable.
This also fixes a range-variable capture bug in load.go: previously we
were deferring a call to clearShouldLoad for the range variable scope.
After this change, we properly clear the ShouldLoad bit for all scopes.
Change-Id: I8f9140a490f81fbabacfc9e0102d9c638c7fbb37
Reviewed-on: https://go-review.googlesource.com/c/tools/+/400821
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Introduce a metadataGraph.Clone method that can be used to clone a
metadata graph, applying a set of updates. During clone, ids and imports
are recomputed from scratch based on the known metadata.
Also refine the check for "real" packages when determining whether a
command-line-arguments package should be kept as a workspace package: if
all other packages are invalid, but the command-line-arguments package
is valid, we should keep the command-line-arguments package.
Updates golang/go#45686
Change-Id: Iea8d4f19c1d1c5a2b0582b9dda5f9143482a34af
Reviewed-on: https://go-review.googlesource.com/c/tools/+/340851
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Now that we preserve stale metadata, we can derive workspace packages
entirely from known metadata and files. This consolidates the logic to
compute workspace packages into a single location, which can be invoked
whenever metadata changes (via load or invalidation in clone).
Additionally:
- Precompute 'HasWorkspaceFiles' when loading metadata. This value
should never change for a given Metadata, and our view.contains func
is actually quite slow due to evaluating symlinks.
- Track 'PkgFilesChanged' on KnownMetadata, since we don't include
packages whose package name has changed in our workspace.
Also introduce a few debug helpers, so that we can leave some
instrumentation in critical functions.
For golang/go#45686
Change-Id: I2c994a1e8ca05c3c42f67bd2f4519bea5095c54c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/340735
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
It is inconsistent to only compute IsIntermediateTestVariant for
workspace packages, and could be a source of bugs. Always compute it.
Change-Id: I16f40fe44a1145a74ef77fee4b7fd813abe603cb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/340732
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In preparation for making metadata immutable, move metadata-related
fields to a new MetadataGraph type. Other than instantiating this type
when cloning, this CL contains no functional changes.
For golang/go#45686
Change-Id: I7ad29d1f331ba7e53dad3f012ad7ecdae4f7d4b7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/340730
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When using go.work, the go command packs module-specific errors into
synthetic results corresponding to the module query ("modulepath/...").
Extract these for use in diagnostics, by packing them into a new
moduleErrorMap error type.
Fixesgolang/go#50862
Change-Id: I68bf9cf4e9ebf4595acdc4da0347ed97171d637f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/405259
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Use a detached Context for all progress notifications. In particular,
using a detached Context for the window/workDoneProgress/create
notification avoids races where the $/cancelRequest notification and
create response cross paths, such that the client has created a progress
dialog but the server thinks that starting progress failed.
Also, as a matter of best practice don't store a context on the WorkDone
type, despite the fact that this Context is detached. Instead, only
close over a Context in the WorkDoneWriter, which requires a Context in
order to function but which implements the io.Writer interface.
The TestProgressBarErrors test should now pass reliably.
Fixesgolang/go#46930
Change-Id: I0d115ed3a62de97fe545c8dc0403e7bb55f6e481
Reviewed-on: https://go-review.googlesource.com/c/tools/+/409936
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
As of golang/go#50827, gopls no longer supports building at 1.12, and so
usage of golang.org/x/xerrors can be replaced with the native support for
error wrapping introduced in Go 1.13.
Remove this usage as a step toward eliminating the xerrors dependency
from x/tools.
For golang/go#52442
Change-Id: Ibf459cc72402a30a6c2735dc620f76ed8a5e2525
Reviewed-on: https://go-review.googlesource.com/c/tools/+/401097
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: I13cf73d7e043dda1a06c28bb09e413a76a68df1f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/391934
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Honor the file kind provided by clients for overlays, by passing the
FileHandle into View.FileKind and checking for overlays.
For golang/vscode-go#1957
Change-Id: I4a767cb64dc5205f1d10c3126a2cbe67c21a34e4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/378314
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Suzy Mueller <suzmue@golang.org>
Make the language id (sent from the client) 'gotmpl' equivalent to 'tmpl'
Wherever a view is known, use its options to determine which files
are template files. Whenever the client sends an explicit
languageID, use that.
Partially fixesgolang/vscode-go#1957
Change-Id: I04cd630d6c6c80e0a78c2fafb6ddc1166ce86829
Reviewed-on: https://go-review.googlesource.com/c/tools/+/376854
Trust: Peter Weinberger <pjw@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
I'm not sure why there was a goroutine in the defer here, but I think
this should fix the flakiness of this test. I wasn't able to reproduce
the flake myself locally however, so I couldn't confirm. I'll leave the
issue open until it stops happening.
For golang/go#47508
Change-Id: Ie9fdc68d70fe1634c3ad001441cf3ce0d2693d17
Reviewed-on: https://go-review.googlesource.com/c/tools/+/342674
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>
In preparation for moving metadata related functionality to a separate
package, move around some types and export some symbols. This is purely
to reduce diffs in subsequent CLs, and contains no functional changes.
Change-Id: I24d4fbd71df78e4d7a84f6598cdf820b41d542a2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/340729
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>
Add the scope to the command-line-arguments package ID and path so that
multiple command-line-arguments packages can coexist in the workspace.
Fixesgolang/go#47584
Change-Id: Icbfe90d67627f384c54f352e46270ab2bf4240bd
Reviewed-on: https://go-review.googlesource.com/c/tools/+/341611
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>
Coupling workspace symbols to package checking means that they do not
function when the workspace is contracted, and also forces us to do
duplicate work traversing file declarations.
This CL changes the workspace symbol implementation to precompute
symbols based only on syntactic information, allowing them to function
in degraded workspace mode, improving their performance, and laying the
groundwork for more significant performance improvement later on.
There is some loss of precision where we can't determine the kind of a
symbol from syntactic information alone, but this is minor: we fall back
on 'Class' if we can't determine whether a type definition is a basic
type, struct, or interface.
Benchmark ("test" in x/tools): 56ms->40ms
Benchmark ("test" in kuberneted): 874ms->799ms
Change-Id: Ic48df29b387bf029dd374d7d09720746bc27ae5e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/338692
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>
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>
Lower the timeout for the go command to 10 minutes.
Also, if the first workspace load attempt fails because it times out,
treat the timeout as a critical error, since we explicitly don't cancel
the first workspace load.
Fixesgolang/go#46859
Change-Id: Iccd26509177e4c47ca4b2c8ab4111df9be0f934e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/330969
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>
The go/packages queries std/... and cmd/... don't work. I believe
they're supposed to be just "std" and "cmd" based on experimentation
(and stdlib_test.go), but I didn't see this explicitly documented.
Fixesgolang/go#46901
Change-Id: I3d0ed48fa64a50eefe4b5cc6074a93455cd37dc8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/330529
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This change adds a shouldLoad field to knownMetadata so that we can be
more selective about reloading these.
If a package has invalid metadata, but its metadata hasn't changed, we
shouldn't attempt to reload it until the metadata changes.
Fixesgolang/go#40312
Change-Id: Icf5a13fd179421b8f70a5eab6a74b30aaf841f49
Reviewed-on: https://go-review.googlesource.com/c/tools/+/298489
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>
Sometimes, we may want to report progress from functions inside of the
cache package, so move the progress tracker to the session to allow for
that.
Change-Id: I15409577a7a5080e7f0224a95d159de42856ffa7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/319330
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>
Retrying CL 271477, this time with parts of CL 322650 incorporated.
This CL moves to a model where we don't automatically delete invalidated
metadata, but rather preserve it and mark it invalid. This way, we can
continue to use invalid metadata for all features even if there is an
issue with the user's workspace.
To keep track of the metadata's validity, we add an invalid flag to
track the status of the metadata. We still reload at the same rate--the
next CL changes the way we reload data.
We also add a configuration to opt-in (currently, this is off by
default).
In some cases, like switches between GOPATH and module modes, and when a
file is deleted, the metadata *must* be deleted outright.
Also, handle an empty GOMODCACHE in the directory filters (from a
previous CL).
Updates golang/go#42266
Change-Id: Idc778dc92cfcf1e4d14116c79754bcca0229e63d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/324394
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>
As part of debugging CL 324394, I found that we were returning
intermediate test variant packages in packageHandlesForFile. This
happened because, even though these packages were not workspace
packages, they would still be picked up by the file URIs -> IDs map.
This is typically not a problem when we are picking out the widest or
narrowest package for a specific request, but for diagnostics on changed
files, we run them on all of the possible packages. This also led to us
analyzing these intermediate test variant packages. Filter them out, as
we will never want them for this purpose.
Change-Id: Ifa780cd104f9c4b3fe6c530402956e2337c8fcdc
Reviewed-on: https://go-review.googlesource.com/c/tools/+/324689
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>
This reverts commit 46e69bf3b2.
Reason for revert: Still has bugs associated with it and want to do a release
Change-Id: Ifa80bde147aa23aa4029a157d5dbaf6479d53024
Reviewed-on: https://go-review.googlesource.com/c/tools/+/324290
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This CL adds two new commands that let a client request a list of importable packages relative to a Go file and then select which import a programmer would like to add to said file.
Updates golang/go#43351
Change-Id: If12518874a92ed4167bdd711a92e03ee21c7b949
Reviewed-on: https://go-review.googlesource.com/c/tools/+/281412
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This CL moves to a model where we don't automatically delete invalidated
metadata, but rather preserve it and mark it invalid. This way, we can
continue to use invalid metadata for all features even if there is an
issue with the user's workspace.
To keep track of the metadata's validity, we add an invalid flag to
track the status of the metadata. We still reload at the same rate--the
next CL changes the way we reload data.
We also add a configuration to opt-in (currently, this is off by
default).
In some cases, like switches between GOPATH and module modes, and when a
file is deleted, the metadata *must* be deleted outright.
Updates golang/go#42266
Change-Id: Iff5e10b641fdb4be270af0cd887a10ee97ac1a19
Reviewed-on: https://go-review.googlesource.com/c/tools/+/271477
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>
Reviewed-by: Robert Findley <rfindley@google.com>
ast.NewPackage mutates the input files, making it difficult to avoid
races with our caching model. I had avoided a race resulting from cache
handle cancellation, just to run into another race in multi-session
servers.
But there's no reason to use ast.NewPackage when we only have a single
file. We can just interrogate the file scope wherever needed.
Fixesgolang/go#45868
Change-Id: I521475b51ee3b1c3e408916affecafbc629b0191
Reviewed-on: https://go-review.googlesource.com/c/tools/+/315629
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>
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>
Collapse Diagnostic.Kind, Source, and Category into just Source. Remove
code that converted from Diagnostic to Diagnostic. Notes on the changes
I had to make along the way:
- We used to use Kind to determine Severity. Set Severity when the
Diagnostic is created instead.
- Use constants for Source as much as possible -- we still need to use
Analyzer.Name for analysis diagnostics. It would be nice to break that
dependency so that Source was totally opaque, but that's a separate
issue.
- Introduce a new Source for gc_details, "optimizer details". It was "go
compiler" previously.
- Some of the assignments are a little arbitrary. Is inconsistent
vendoring really a "go list" error?
- GetTypeCheckDiagnostics had code to cope with diagnostics that had no
URI associated with them. We now spread such diagnostics to all files
when they are generated.
- Analyze modifies Diagnostics by adding a Tag to them. That means it
has to own them, so I had it clone them. I would like to push that logic
down to the diagnostics, per the TODO, but that's another CL.
And some observations:
- It's obviously tempting to combine DiagnosticSource and
diagnosticSource, but they mean very different things. I'm open to a
better name for one or the other.
Change-Id: If2e861d6fe16bfd2e5ba216cf7e29cf338d0fd25
Reviewed-on: https://go-review.googlesource.com/c/tools/+/288215
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 existing test didn't catch it because it doesn't look for specific
warning messages.
Change-Id: I1ec7f7a75c1055c960cdd7545331c2fd655e3aa8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/281860
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
The fragmentation of the critical error reporting is getting in the way
of small fixes. This change adds a GetCriticalError function that reports
critical errors, while ModTidy and WorkspacePackages no longer report
critical errors. Any function that wants to process critical errors
should call AwaitLoaded.
Some other smaller changes are made to account for these changes. One
change is that we may report multiple *source.Errors, with the
assumption that duplicate diagnostics will be caught by the diagnostic
caching. Also, any `go list` error message that ends with "to add it" is
now considered an error that gets the "add dependency" suggested fix.
Fixesgolang/go#43338Fixesgolang/go#43307
Change-Id: I056b32e0a0495d9a1dcc64f9f5103649a6102645
Reviewed-on: https://go-review.googlesource.com/c/tools/+/280093
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Package.ID() is far more useful to tag on events, as it disambiguates
multiple packages with the same path.
Change-Id: I03fd69f64641eb17155ca72ed2ef19641b75f004
Reviewed-on: https://go-review.googlesource.com/c/tools/+/279722
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: Rebecca Stambler <rstambler@golang.org>
This change adds a diagnostic and error message that appears when a user
edits a nested module in legacy mode. At first, I thought a diagnostic
would be enough, but it's actually quite difficult to spot it when you
have a bunch of "undeclared name" diagnostics caused by the nested
module, so I figured a progress bar error message would also be useful.
This error message just indicates to the user that they should open the
nested module as its own workspace folder.
Also, while debugging this, I noticed that command-line-arguments
packages can have test variants, which we were never handling.
So I addressed that in this change.
Fixesgolang/go#42109
Change-Id: Ifa6f6af401a3725835c09b76e35f889ec5cb8901
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275554
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For every file change, we want to diagnose the resulting snapshots.
However, we also want to diagnose the file in its "best possible" view
(for example, for a nested module, we should use the inner module rather
than the outer module).
Add a bestView function that operates on a set of views, which allows
us to a pick a view out of the *views affected* by a file modification,
not out of *all* of the views in the session. This means that we can
pick the best view, if any, for each file change and then only return
the snapshots that we should diagnose, as well as the changed URIs for
those snapshots.
Fixesgolang/go#42890
Change-Id: Iad23d5ed4832dfd857f1424a7244cf3bd8900e3b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274235
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>
The "you are neither in a module nor your GOPATH" warning doesn't fit
our current notification style, so adjust it to appear as a progress
report and clean up the associated tests.
Change-Id: I32b96f17f3b9715403e465e3e0f9705f5d859147
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275537
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>
Users working in large repositories may want to include only selected
directories in their workspace to avoid memory usage and performance
slowdowns. Add support for inclusion/exclusion filters that control what
directories are searched for workspace packages and modules. Packages
that are excluded by the filter may still be loaded as non-workspace
packages if other things depend on them.
For a description of the option's syntax, see the documentation.
Note that because we don't have any way to communicate the filters to
packages.Load, we still run go list on the unfiltered workspace scope,
then throw away the irrelevant packages. That may cost us, especially in
workspaces with many files.
Comments on the naming welcome. Also, if you know any places I may have
missed applying the filter, please do tell. One thing I thought of is
file watching, but that's covered because allKnownSubdirs works off of
workspace files and those are already filtered.
Possible enhancements:
- Support glob patterns.
- Apply filters during the goimports scan.
- Figure out how to apply the filters to packages.Load. I don't know
how to do it while still being build system neutral though.
Closesgolang/go#42473, assuming none of the enhancements are required.
Change-Id: I9006a7a361dc3bb3c11f78b05ff84981813035a0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275253
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>
When GO111MODULE=auto and the workspace is outside of $GOPATH/src, we
should still show diagnostics about how to correctly configure
multi-module workspaces. We should not show these warnings for
workspaces outside of a module within GOPATH.
This adds an extra piece to the WorkspacePackages error logic--we may
still need to show the errors even if WorkspacePackages returned
results. We should eventually consolidate all of this logic to be more
cohesive, but for now I think it's more important to cover all of the
different cases and add tests.
Updates golang/go#42109
Change-Id: I673a03c9840cdaaf7f058de1cda3bf36b96fa7d3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275553
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
When running with -mod=readonly, we need a go.sum to be present for go
command invocations. Achieve this by merging the go.sum of tracked
modules.
Fixesgolang/go#42509
Change-Id: I36dd084f865ebcee0ba6e1e542fdf51031b1487e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272886
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
We adjust the value of GO111MODULE to "auto" when running the go
command, since it handles more edge cases. However, in some cases, we
may want to know the environment's actual value of GO111MODULE, so
separate out these two concepts.
Also, as of Go 1.13, `go env` reports GO111MODULE, so add it to the
environmentVariables, but only for Go versions >= 1.13.
Removed a regression test that doesn't seem very important--looks like
even `go env` will fail with GO111MODULE=on and a malformed GOPATH.
I don't think that it's important that `gopls` continue working in such
a case, since the go command will also fail.
Change-Id: I8147782222261a190d0f1017fe9f6043f2ac0cdb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275013
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>
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>
Currently, when a user opens a workspace with no top-level module but
multiple modules in subdirectories, gopls treats that as an invalid
build configuration and reports an error message that may be difficult
for the user to understand (a go list error message about creating a
main module in the top-level directory). Instead, show a more useful
error message about the gopls workspace layout in both the progress bar
and as a diagnostic on every open file.
This fix only works for GO111MODULE=on (for now) because it's a lot
easier to interpret user intent, and the go command will return no
packages. The next step will be to improve error messaging for
GO111MODULE=auto and for users with nested modules.
Updates golang/go#42109
Change-Id: I702ca6745f7e080ff6704ade7843972ab469ccf3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272346
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>
Ruslan Nigmatullin
Robert Findley
Dan Kortschak
pjw
Rebecca Stambler
Marwan Sulaiman
Heschi Kreinick