x/tools/gopls: parallelize initial workspace load #36463
Comments
gopherbot
added
Tools
|
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 |
|
@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, Which also means we won't pick up/be able to test any features that land subsequently. |
|
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. |
|
This work is now completed. |
goplsneeds 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:/cc @myitcv @leitzler
The text was updated successfully, but these errors were encountered: