rust_hdl
rust_hdl copied to clipboard
VHDL-LS
Avoid sending diagnostics for all files on every change
The LSP protocol supports client caching for diagnostics on a file-level. Currently VHDL-LS publishes all diagnostics for every edit. This works well when there are few diagnostics but is not optimal. When adding dead code detection many code bases could have larger amount of diagnostics. We could thus optimize this.
Another benefit is that it simplifies the code inside vhdl lang since caching does not need to be handled there.
Just tagging @Schottkyc137 here
By tagging I assume you want this prioritised?
By tagging I assume you want this prioritised?
That would be very nice indeed!
@kraigher just to confirm, I couldn't find any information about the client actually being forced to to cache diagnostics. However, there is the pull-based diagnostic model where the client periodically asks the server to compute diagnostics for a certain file. There, one can send an UnchangedDocumentDiagnosticReport, indicating that a file has no new diagnostic, and the old version should be used. Is this what you are referring to? If so, are you suggesting to switch to this new model or keeping both, using the push-based version when the pull-based is not available?
From the LSP spec:
When a file changes it is the server’s responsibility to re-compute diagnostics and push them to the client. If the computed set is empty it has to push the empty array to clear former diagnostics. Newly pushed diagnostics always replace previously pushed diagnostics. There is no merging that happens on the client side.
This means the client has to remember what diagnostics the server sent until the server sends another publish diagnostics for the file.
I do not think it is a good model for the client to poll the server for diagnostics. That is only useful for simple LSP servers where checks are only done in a single file. In a project wide LSP a removed definition in one file would trigger an unknown variable error in another file. You always wants the full diagnostics of the entire project tp be updated and only the server can manage that.
Ah, I see what you mean. Makes sense to me, even though the pull-based approach also has methods to resolve the inter-file dependency. Still, I think the push-based approach is better. I'm a bit confused, however, about the "it simplifies the code inside vhdl lang since caching does not need to be handled there" part. How would you optimise caching? Not sending diagnostics for every file means that we need to check whether we need to re-send diagnostics for every file after analysis. Without pretty big adaptations to the analysis stage and / or more complex dependency tracking, I don't see how this would work? Or are you only referring to the parser diagnostics, since parser diagnostics can only affect a single file?
The main use case for this issue was someone having 10000 warnings that became slow to resend over json rpc for every change. If there as a cache in the vhdl-ls crate that knew the diagnostics it published for every file before it could avoid resending every diagnosic to the client on every change and only publish diagnostics for files that changed.