[PATCH] D75739: [clangd][vscode] Enable dot-to-arrow fixes in clangd completion.

Haojian Wu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Mar 9 02:39:34 PDT 2020


hokein marked 2 inline comments as done.
hokein added a comment.

In D75739#1909637 <https://reviews.llvm.org/D75739#1909637>, @sammccall wrote:

> So the core of this is a better version of my patch, thanks!
>  It does work around the problem with dot-to-arrow, which is useful and we should definitely enable that.
>
> We get into this mess because we merge two edits together, I think to avoid LSP's vague prohibition about edits related to the cursor. My vote would be:
>
> 1. check this patch in, but without claiming it as the correct and carefully architected fix for dot-to-arrow
> 2. try turning off range-merging, and test it in a couple of clients (including vscode *without* this patch)
> 3. if it works, make that change in clangd


I think if we do that, we are likely to go back to the issue <https://github.com/microsoft/language-server-protocol/issues/543> that sending additionalEdit related to the cursor, and LSP clearly states it is not supported -- `Additional text edits should be used to change text unrelated to the current cursor position`, and it would not work in VSCode.

> However I actually think the dot-to-arrow problem is our bug at this point. LSP is vague but the discussion on language-server-protocol#898 very sensibly links filterText to textEdit.range. If we're sending filterText = "foo", textEdit.range = ".f" then I don't think that *is* a match.

Regarding the mismatch between filterText and textEdit.range, there is another way to make them matched -- sending `filterText=".foo"` (rather than `foo`) from clangd,  vscode should work without this patch, but it looks like a hack in clangd to me...

> How does this handle cases where an object overloads the -> operator or worse still overloads the operator and has conflicting names when accessed with .  or ->.

This patch shouldn't affect the existing behavior for the mentioned case,  it is handled by Sema. VSCode will show both candidates (one of them will correct the `.` while the other will not).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75739/new/

https://reviews.llvm.org/D75739





More information about the cfe-commits mailing list