diff options
| author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2020-11-05 13:09:22 +0000 |
|---|---|---|
| committer | GitHub <[email protected]> | 2020-11-05 13:09:22 +0000 |
| commit | 7709b6a2d4b74b5838fbe5b30b6188d6a549b580 (patch) | |
| tree | 31f0539c641e7a793aeed4d4cb6189e8c1e2a5d7 /crates/hir_ty/src/tests/coercion.rs | |
| parent | f5b72638bd5a18c4ddbd577930b5deaf64306034 (diff) | |
| parent | d2bf2ebe15bd58e6d8937a5894a2363a1ca46b59 (diff) | |
Merge #6470
6470: Restore semantic token flickering workaround removed in #5697 r=kjeremy a=charlespierce
Closes #6452
Info
-----
* As discussed in #6452, the `Error('busy')` workaround for semantic token flickering was removed because the underlying issue was believed to be fixed in VS Code.
* It turns out that the fix isn't yet complete, so this caused flickering of the semantic highlighting when making rapid edits (e.g. typing quickly).
* This PR restores that workaround and makes it slightly more robust, covering all areas of semantic token middleware.
Changes
-----
* Added middleware functions for `provideDocumentSemanticTokens`, `provideDocumentSemanticTokensEdits`, and `provideDocumentRangeSemanticTokens` to match the 3 possible middleware hooks defined in https://github.com/microsoft/vscode-languageserver-node/blob/master/client/src/common/semanticTokens.ts#L33
* Each intercepts a `null` or `undefined` return and throws an error with the message `busy` instead, which prevents the tokens from being removed and re-added (causing the flickering behavior)
Tested
-----
* Tested locally that the flickering behavior is gone.
* There don't appear to be any significant tests of the VS Code plugin side of things, other than that it loads. Is there somewhere I can / should add tests to cover this behavior?
Co-authored-by: Charles Pierce <[email protected]>
Diffstat (limited to 'crates/hir_ty/src/tests/coercion.rs')
0 files changed, 0 insertions, 0 deletions