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: diff metadata before invalidating on changes to go.mod #36589

Open
stamblerre opened this issue Jan 16, 2020 · 1 comment
Open
Labels
gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@stamblerre
Copy link
Contributor

Right now, gopls invalidates all workspace metadata if there is a change to the user's go.mod file. This is unnecessary if the metadata remains valid after the change. @heschik proposes running go list -m all as a gate during the snapshot cloning to determine if we should invalidate all metadata or keep it in the cache. Either way, we will either invalidate all metadata for the workspace or none.

@gopherbot gopherbot added this to the Unreleased milestone Jan 16, 2020
@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 Jan 16, 2020
@stamblerre stamblerre added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 16, 2020
@stamblerre stamblerre modified the milestones: Unreleased, gopls/v1.0.0 Jan 16, 2020
@stamblerre stamblerre modified the milestones: gopls/v1.0.0, gopls/v0.5.0 Mar 12, 2020
@stamblerre stamblerre modified the milestones: gopls/v0.5.0, gopls/v0.6.0 Apr 2, 2020
@stamblerre stamblerre removed this from the gopls/v0.6.0 milestone Jun 24, 2020
@stamblerre stamblerre added this to the gopls/unplanned milestone Oct 21, 2020
@findleyr
Copy link
Contributor

CC @adonovan

I think this is less urgent now that we only invalidate on saves to go.mod, go.work, etc., but also we're pretty close to being able to do this after recent refactorings to invalidation and loading. It would be easy to avoid applying metadata changes if no diff was detected in cache.buildMetadata.

The problem is getting the package invalidation correct to avoid layering problems: when we invalidate metadata in snapshot.clone, we also invalidate computed packages. With the current caching model, these packages get evicted ~immediately, so even if metadata has not changed following the load they need to be recomputed. If we don't invalidate immediately, then we have packages in the snapshot whose metadata does not match the stored metadata. As we have seen, maintaining such invariants is crucial.

I think the cleanest way to achieve this may be to not do metadata invalidation in snapshot.clone, but just schedule a reload (c.f. https://go.dev/cl/417576). Then, create a new snapshot on load. This has the advantage of making metadata in the snapshot fully immutable. Along with #42814, we can move toward a model where the snapshot is entirely immutable, save for lazily computed promises.

Moving this to the gopls/later milestone.

@findleyr findleyr modified the milestones: gopls/unplanned, gopls/later Aug 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

3 participants