Remove some duplication in the construction of cache.workspace
instances.
For golang/go#44696
Change-Id: Ic955fa3f9a574781f627c550694f0b87ad2013e1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/382114
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Gopls was using an old version of workfile support in x/mod that did not
support the 'use' syntax.
Upgrade to x/mod@master, and update tests accordingly.
For golang/go#44696
Change-Id: I87841cd1322d7b1aa0fbc929838746ea600bee77
Reviewed-on: https://go-review.googlesource.com/c/tools/+/382078
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change handles the case of the user creating a go.work file
during the gopls session. It also defaults to go.work/gopls.mod being
used outside of experimental mode, so that you don't have to both set
a setting and have a file.
Change-Id: If118cd2fc95c1b5600a6c06217a3b61605b11e28
Reviewed-on: https://go-review.googlesource.com/c/tools/+/342170
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>
Allow users to experiment with golang/go#45713 by adding experimental
support for the go.work file. We handle it like a special case, very
similar to the current gopls.mod file mechanism. The behavior is
undefined if both a gopls.mod and go.work file exist. Ultimately, we
will deprecate support for the gopls.mod file if the go.work file
proposal is accepted, so I don't think it's important to be careful
about handling both simultaneously.
Change-Id: Id822aeec953fc1d4acca343b742afea899dc70ff
Reviewed-on: https://go-review.googlesource.com/c/tools/+/328334
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>
Invalidating the workspace on any change to a go.mod can render a
workspace unusable. Only invalidate when changes are saved.
Additionally, invalidate the workspace if there is a saved change to
tracked go.sum changes.
Fixesgolang/go#42529Fixesgolang/go#42815
Change-Id: I5d903013b33b932eca4998513e3d0a534b2e5a61
Reviewed-on: https://go-review.googlesource.com/c/tools/+/279720
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>
We were getting duplicate diagnostics for certain mod tidy diagnostics.
The correct fix is to separate out the generation of such diagnostics
so that duplicates don't occur, but for now, this is the simplest fix.
I wanted to add a test, but my repro case involves `go clean -modcache`
and checking that a version cannot be downloaded, which doesn't work
with the file-based GOPROXY. I will probably have a CL at some point
that cleans up the way these diagnostics are produced.
Change-Id: I542648b4eae7aced15f720db6233c852879f2a26
Reviewed-on: https://go-review.googlesource.com/c/tools/+/278917
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>
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 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>
In some cases (such as presenting more helpful error messages), we need
to know the number of go.mod files in the workspace--not just the
active go.mod files. Track both known and active mod files separately.
Change-Id: I068f76c2930c90cd0fdf5ce637e5934210880f65
Reviewed-on: https://go-review.googlesource.com/c/tools/+/273047
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>
Previously, we had an optional file search limit in the findModules
function. We should stay consistent, so change that to a non-optional
default of 1 million files. We should adjust this if it's necessary to
reduce the limit.
Change-Id: I2664a8760362d03d40867c8208ae0b83111cd4f4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/273307
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>
We don't check the value of GO111MODULE before finding all of the
modules in the workspace, meaning we treat the workspace as if it has
modules even if modules are disabled. Before creating a workspace,
we now do check this.
Change-Id: I36b9d13f3b8382e65de36b4b4deed68f5b59e21d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/273309
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>
We currently have partial, untested support for symlinks. Remove all
support for now until we come up with a decision.
I thought we could re-enable the OpenBSD trybot since we think it was
failing because of the latency of evaluating symlinks, but it seems like
it's still failing.
Updates golang/go#42833
Change-Id: Iece1741def4eaaeffe5fecd10f884c1cce87f449
Reviewed-on: https://go-review.googlesource.com/c/tools/+/273190
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>
If the user opens a parent directory of a single module, we can load
their workspace without using some of the workarounds of experimental
workspace mode, simply by narrowing the workspace to this nested
subdirectory.
Do this by extending findAllModules to support a limit on the number of
modules and files to search.
Updates golang/go#41558Fixesgolang/go#42108
Change-Id: Idba800a0deaeee5137d46f16a30b2012ff902a36
Reviewed-on: https://go-review.googlesource.com/c/tools/+/268877
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>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Robert Findley <rfindley@google.com>
Running `staticcheck ./internal/lsp/...` turned up a few instances of
dead code. Remove them.
Change-Id: Ic53db59cd0959fad960b086158eb550a624a4d91
Reviewed-on: https://go-review.googlesource.com/c/tools/+/268580
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: Heschi Kreinick <heschi@google.com>
The logic that checked if a file was already being watched by the
default glob pattern was incorrect. Fix it, and use the newly added
InDir function.
Change-Id: Ia7e3851ab5b9fa1fa7590cae3b370676201a9141
Reviewed-on: https://go-review.googlesource.com/c/tools/+/267119
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 copies the logic from the go command's inDir function
(https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/search/search.go;drc=3931cc113f3f3e7d484842d6e4f53b7a78311e8e;l=570)
to replace gopls's "isSubdirectory" function. This function resolves
symlinks, which isSubdirectory did not previously do.
The only adjustments are to flip the arguments to match the previous
signature of isSubdirectory and to return a boolean instead of a string.
Fixesgolang/go#38558
Change-Id: I9c64604222ac277eae81a4111eef432ead887e9f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/266200
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>
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>
Robert Findley
Rebecca Stambler
Heschi Kreinick