Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
x/tools/gopls: add a custom command to ask the server if diagnostics are all sent #36518
Right now, there is no way for the client to tell if all possible diagnostics have been sent for a given file. This is fine for normal editing, but it makes tests difficult to write. We thought that having a policy of always sending diagnostics on
FWIW some background from the
We split the
I think the problem you are describing is covered by the second bucket:
The second bucket of tests is not complete, but currently we assert that:
The tricky part in all of this is asserting that we have not received a diagnostic in a given situation. For that we use a sleep (configurable, but it is a generous 30s on CI) followed by a check that the count of diagnostics notifications (since the last check) is zero:
We skip these tests if
Whilst not yet complete, I'm fairly comfortable that we have the machinery required to get full coverage via this second bucket. Yes the sleep approach is not ideal, but it at least has the benefit of not requiring further changes to
Indeed any method of the sort you propose would presumably need to block on any in-flight diagnostics calculations before returning?
All that said we'd be very open to improving our approach and making our tests more reliable.
Can you explain a bit more about how this is related? Much like our approach in bucket 1 above, if you assume that
If actually you were suggesting above that we should drop the re-sending of diagnostics on file open then I agree, for the reasons I explained.
But then also for the reasons I explained I'm not sure we need a method for our tests to tell if all possible diagnostics have been sent for a given file. It might help clean up/simplify the tests a bit but I'm not sure it's worth the effort at this point if we can get coverage by other means. But I obviously say that with far less experience of the
For govim tests I agree that this command is probably unnecessary. As you said, govim is typically asserting on the receipt (or non-receipt) of diagnostics. In most of these cases, the govim tests shouldn't really care about the exact content of these diagnostics.
On the other hand, this is useful for the type of tests @heschik was looking at, which are testing the specific contents of the diagnostics.
Eh, I think what I said above is a bit of a mischaracterization. Both govim and gopls have at least one common concern with respect to diagnostics: knowing whether all diagnostics have been received. IIUC both are currently using a timeout to achieve this.
This mechanism already exists (diagnostics are ~idempotent), so what @heschik did was pretty simple: https://golang.org/cl/214583. Seems like that's a relatively small cost for the benefit of not having to rely on timeouts.
I'll defer to @heschik regarding whether this should be used by govim, or whether we prefer this remain an internal API.
Quick update here based on my comment above (no need to re-open).
When govim/govim#678 lands we will move almost entirely away from blocking based on diagnostic messages from
Instead, per the commit message, we will use
Per @findleyr's comment above, this is much better suited (thanks for the suggestion, @findleyr!) to