x/tools/gopls: infer workspace modules from a user-provided gopls.mod #41837
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
gopherbot
added
Tools
|
Change https://golang.org/cl/261237 mentions this issue: |
|
Change https://golang.org/cl/263897 mentions this issue: |
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 <[email protected]> gopls-CI: kokoro <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Heschi Kreinick <[email protected]> Trust: Robert Findley <[email protected]>
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 <[email protected]> gopls-CI: kokoro <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Rebecca Stambler <[email protected]> Trust: Robert Findley <[email protected]>
|
@findleyr: Can this be closed? |
Yep! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Tracking issue for the work @findleyr has been doing on the user-provided
gopls.modfile, which can be used to override gopls's automatically created workspace module.The remaining tasks are:
gopls.mod, and instead populate the modules map by looking at thegopls.mod's requires.gopls.modgopls.mod: We should look "upwards" for ago.modor agopls.mod, stopping at the firstgopls.mod. Thegopls.modalways beats thego.mod.The text was updated successfully, but these errors were encountered: