Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: infer workspace modules from a user-provided gopls.mod #41837

Closed
3 tasks done
stamblerre opened this issue Oct 7, 2020 · 4 comments
Closed
3 tasks done
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@stamblerre
Copy link
Contributor

stamblerre commented Oct 7, 2020

Tracking issue for the work @findleyr has been doing on the user-provided gopls.mod file, which can be used to override gopls's automatically created workspace module.

The remaining tasks are:

  • Do not search for workspace modules in the presence of a gopls.mod, and instead populate the modules map by looking at the gopls.mod's requires.
  • Handle on-disk modifications to the gopls.mod
  • Detecting a gopls.mod: We should look "upwards" for a go.mod or a gopls.mod, stopping at the first gopls.mod. The gopls.mod always beats the go.mod.
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Oct 7, 2020
@gopherbot gopherbot added this to the Unreleased milestone Oct 7, 2020
@stamblerre stamblerre modified the milestones: Unreleased, gopls/v1.0.0 Oct 7, 2020
@gopherbot
Copy link

Change https://golang.org/cl/261237 mentions this issue: internal/lsp/cache: introduce a workspaceModule abstraction

@gopherbot
Copy link

Change https://golang.org/cl/263897 mentions this issue: internal/lsp/cache: consider gopls.mod when finding workspace root

gopherbot pushed a commit to golang/tools that referenced this issue Oct 30, 2020
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>
gopherbot pushed a commit to golang/tools that referenced this issue Oct 30, 2020
gopls.mod files should take precedence over go.mod files when finding a
workspace root. To allow this, implement our own algorithm for expanding
the workspace, rather than using the go command.

For golang/go#41837

Change-Id: I943c08bdbdbdd164f108e44bae95d2c659a6e21e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/263897
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>
@stamblerre
Copy link
Contributor Author

@findleyr: Can this be closed?

@stamblerre stamblerre moved this from To Do to Assigned in multi-module workspaces Nov 11, 2020
@findleyr
Copy link
Contributor

@findleyr: Can this be closed?

Yep!

@stamblerre stamblerre moved this from Assigned to Done in multi-module workspaces Nov 18, 2020
@golang golang locked and limited conversation to collaborators Nov 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
No open projects
Development

No branches or pull requests

3 participants