Open Aloso opened 4 years ago
I would say that that is the editor issue. We could shift diagnostics on our side, but I feel that the client is in much better position to do this.
@matklad should I file an issue for VS Code then?
I'm afraid they'll just say it's the extension's fault.
I am 90% sure that an issue about shifting diagnostics exists either in VS Code or LSP repo, so it's better to search for one first.
On Mon, 20 Apr 2020 at 16:09, Ludwig Stecher notifications@github.com wrote:
@matklad https://github.com/matklad should I file an issue for VS Code then?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rust-analyzer/rust-analyzer/issues/4056#issuecomment-616578513, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANB3MZDRMC43UGM65EB3QTRNRJRJANCNFSM4MMOLO5A .
@matklad I searched both repos for issues and couldn't find anything.
I noticed that the bug only occurs after rust-analyzer is finished analyzing the project. Could this be related to semantic highlighting or something similar?
I think I found a relevant issue on the LSP repository, namely https://github.com/microsoft/language-server-protocol/issues/318
If I understood that correctly, they're saying that it's entirely optional for editors to move diagnostics.
When I modify a file in VS Code containing errors from
cargo check
, the red squiggly lines often don't move with the text. Instead they remain in the very row and column where they were when the file was last saved.The behavior is somewhat unpredictable. For instance, if I open a project where a file is already opened from the previous session, this bug does not appear in this file, until it is closed and re-opened again.
P.S. I use VSCodium on Manjaro/KDE.