<div dir="ltr"><div>Hi,</div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>Two possible fixes I can see are:</div><div><br></div><div>1. Remove the check (from a quick test clangd still functions perfectly after commenting out the check).</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I'm not sure which solution would be preferred so I'm posting here first before implementing a fix.</div><div><br></div><div>Regards,</div><div><br></div><div>Daan De Meyer<br></div></div>