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: parallelize initial workspace load #36463

Closed
stamblerre opened this issue Jan 8, 2020 · 4 comments
Closed

x/tools/gopls: parallelize initial workspace load #36463

stamblerre opened this issue Jan 8, 2020 · 4 comments
Labels
Milestone

Comments

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Jan 8, 2020

gopls needs to load the user's workspace in order to correctly create diagnostics and produce correct results for find references and implementations. Currently, we start a goroutine to load and diagnose a view whenever one is added. This produces diagnostics which are then sent to the client. To avoid blocking on this usually slow initial workspace load, we start it in its own goroutine, but this can conflict with user's opening and changing files. Some key fixes need to be made for this to work correctly:

  • The initial workspace load must not be canceled
  • The initial workspace load must not send out of date diagnostics

/cc @myitcv @leitzler

@myitcv

This comment has been minimized.

Copy link
Member

@myitcv myitcv commented Jan 9, 2020

Just to add one thought: the initial workspace load should always send diagnostics at version 0 for files. At the moment the initial workspace load races with any files that might be being opened/already open, and so we can end up with multiple diagnostics for the same version. I think we have to avoid this because the initial workspace load does not include analysis results whereas the file open does. Hence if both had the same version we'd have no reliable way of determining which one is "correct"/current

@myitcv

This comment has been minimized.

Copy link
Member

@myitcv myitcv commented Jan 9, 2020

@stamblerre depending on how long you think it will be before fixes land, does it make sense to revert https://go-review.googlesource.com/c/tools/+/212102 in the meantime? That way a stack of changes including a re-run of https://go-review.googlesource.com/c/tools/+/212102 can be tested separately.

As it stands, govim is currently having to use a temporary fork: govim/govim@afa4918

Which also means we won't pick up/be able to test any features that land subsequently.

@stamblerre

This comment has been minimized.

Copy link
Contributor Author

@stamblerre stamblerre commented Jan 9, 2020

The initial workspace load should be operating on an earlier snapshot, so it's definitely a bug if it is sending diagnostics with versions other than 0. I don't think it's worth reverting that CL, since I have a number of follow-up changes for it, and I am actively investigating the bugs with it.

@stamblerre

This comment has been minimized.

Copy link
Contributor Author

@stamblerre stamblerre commented Jan 15, 2020

This work is now completed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.