[clangd-dev] DraftStore::updateDraft compares lsp's rangeLength in UTF16 code units against the computed rangeLength in bytes
Daan De Meyer via clangd-dev
clangd-dev at lists.llvm.org
Sun Oct 21 11:53:00 PDT 2018
I've started using clangd with VSCode and discovered an issue when
accidentally typing a unicode character and immediately removing it
afterwards. When removing the unicode character clangd errors with:
"Change's rangeLength (1) doesn't match the computed range length (3)".
Afterwards, clangd doesn't work for the current file until it is restarted.
Since I had to build LLVM anyways to add support for passing relative paths
to -compile-commands-dir, I tried to debug this issue as well. What I've
discovered is that when the range length's are compared in
DraftStore::updateDraft (DraftStore.cpp:80) , the LSP's range length seems
to be specified in UTF16 code units while clangd's computed range length is
specified in bytes (see positionToOffset in SourceCode.hpp:83). This causes
the check to fail which causes the error in VSCode.
Two possible fixes I can see are:
1. Remove the check (from a quick test clangd still functions perfectly
after commenting out the check).
2. Use the StartIndex and EndIndex to get a substring from the Contents
variable from which we can then calculate the computed range length in
UTF16 code units using the utf16Len function (SourceCode.cpp:72). This
would require lifting out the utf16Len function into SourceCode.h or
elsewhere since at the moment it's a static function in SourceCode.cpp.
I also checked the LSP docs and they don't explicitly say the rangeLength
is specified in UTF16 code units. However, I'm assuming it is since a LSP
Range consists out of two LSP Positions of which the LSP Character field is
specified in UTF16 code units.
I'm not sure which solution would be preferred so I'm posting here first
before implementing a fix.
Daan De Meyer
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the clangd-dev