Syntax Highlighting in VS Code Flickers when typing quickly

[charlespierce]

When using rust-analyzer with VS Code, I've just started to see a flicker in the syntax highlighting when typing quickly. If I type slowly enough, no flickering happens, but if I type quickly (or hold down the backspace key to quickly remove several characters), the syntax highlighting keeps flickering.

It looks like it's switching between the correct highlighting and the highlighting that is used before r-a fully boots up. That is, while typing the coloring switches to the basic version that is used before r-a is done indexing everything and then catches up and switches back to the full highlighting.

I've tested with r-a nightly and still see the same behavior, though I don't see it in any other languages in VS Code.

OS: MacOS Catalina 10.15.7
VS Code: 1.50.1

[matklad]

cc @kjeremy I think you have the most context about this. We used to through some kind of special error to signal cancellation, but maybe that fix got removed with some upgrade to VS Code? If you don't remember of the top of your head, I'll dig into this.

[bjorn3]

I can occasionally reproduce it when holding a key or typing garbage very fast. It then happens like once every 10s. I haven't seen it in under normal circumstances though. I did notice that r-a consumed 100% cpu when I ctrl-tab to an htop window just after typing garbage very fast.

[matklad]

I did notice that r-a consumed 100% cpu when I ctrl-tab to an htop window just after typing garbage very fast.

Hm, good catch! I wonder if that means that we miss some coalescing of update notifications...

[charlespierce]

In my case, I don't have to type very quickly to get it to happen, I notice it when typing normally. I restarted my machine just to make sure there wasn't anything long-running that was eating up memory / cpu, but it still happened with nothing else open.

It also seems to occasionally get stuck on the "bad" highlighting, even after I stop typing[1]. I know nothing about the architecture of the VS Code plugin, but maybe something with multiple async updates coming back in the wrong order?

[1] Screenshot of the "bad" formatting stuck even after I finished typing (note the mod names are white and the lifetime annotations have the ' character white but the rest the same color as the type name):

Compared with the "expected" formatting after I typed a little more (now the mod names are colored and the lifetime annotations are correctly handled as their own color):

[kjeremy]

I removed the flicker fix in #5697 because I thought that it was fixed in vscode 1.44. However It looks like I was mistaken. The vscode side of this is being tracked in microsoft/vscode#93686 Maybe that PR should be reverted and updated to account for the latest protocol changes.

[matklad]

Hm, good catch! I wonder if that means that we miss some coalescing of update notifications...

Looked at this. The 100% CPU is basically how the things are implemented -- we do manage to process keypresses faster than they arrive, and we do canellation properly. The fix for this partiuclar issue would be to implement some smarter batching of changes, but it seems low-priority.

[matklad]

@kjeremy yeah, from what I gather, they've implemented server-side thing to update notifiacations, but didn't do anything with serve-side canellations. Seems like we need to bring that middleware back, sigh. Would you send a PR ^^?

[kjeremy]

@kjeremy yeah, from what I gather, they've implemented server-side thing to update notifiacations, but didn't do anything with serve-side canellations. Seems like we need to bring that middleware back, sigh. Would you send a PR ^^?

Yep! I can whip one up later this week.

[charlespierce]

@kjeremy I'd be happy to take a swing at it, if you can point me towards the protocol changes you mentioned would need to be taken into account.

[kjeremy]

@charlespierce certainly! I think what needs to happen is to revert #5697 and just make sure that all the types match. For instance the middleware doesn't just return SemanticTokens anymore it will also need to handle SemanticTokensEdits (maybe reverting the PR is enough? I haven't looked) and we should probably provide an analogous middleware piece for DocumentRangeSemanticTokensProvider.

[charlespierce]

@kjeremy Opened #6470 which fixes the flickering and (I think) matches the protocol provided by the LSP