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

[hokein]

Summary

The previous issue is that the item was filtered out by vscode, because
the prefix (which contains ".") are not matched against the filterText.

This patch works around it by adjusting the item filterText, inspired by
https://reviews.llvm.org/D75623.

[sammccall]

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.

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.
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

clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts

118–121

"This also prevents VSCode from filtering out any results due to differences in how fuzzy filtering is applied."

129

While the detailed examples/debugging instructions are nice for me, I don't think keeping them in the code here is worthwhile - I'd suggest just adding the one line to the comment above and removing this block.

For the dot-to-arrow example specifically it might be worth filing a clangd bug and linking to it in the comment above.

[njames93]

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 ->.

[hokein]

address comments.

[hokein]

In 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 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).

[sammccall]

In D75739#1912051, @hokein wrote:

In 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 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.

Sure, well if it doesn't work, then we should keep this hack instead.

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...

Yes. And worse, it's a hack that's pretty hard to implement :-)

clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts

logFailedRequest(rpcReply: vscodelc.RPCMessageType, error: any) {
     if (error instanceof vscodelc.ResponseError &&
         rpcReply.method === "workspace/executeCommand")
       vscode.window.showErrorMessage(error.message);
     // Call default implementation.
     super.logFailedRequest(rpcReply, error);
   }
 }
 
+class EnableEditsNearCursorFeature implements vscodelc.StaticFeature {
+  initialize() {}
+  fillClientCapabilities(capabilities: vscodelc.ClientCapabilities): void {
+    const extendedCompletionCapabilities: any =
+        capabilities.textDocument.completion;
+    extendedCompletionCapabilities.editsNearCursor = true;
+  }
+}
+
 /**
  *  this method is called when your extension is activate
  *  your extension is activated the very first time the command is executed
  */
 export function activate(context: vscode.ExtensionContext) {
   const syncFileEvents = getConfig<boolean>('syncFileEvents', true);
 
   const clangd: vscodelc.Executable = {
const clientOptions: vscodelc.LanguageClientOptions = {
         revealOutputChannelOn: vscodelc.RevealOutputChannelOn.Never,
 
         // We hack up the completion items a bit to prevent VSCode from re-ranking them
         // and throwing away all our delicious signals like type information.
         //
         // VSCode sorts by (fuzzymatch(prefix, item.filterText), item.sortText)
         // By adding the prefix to the beginning of the filterText, we get a perfect
         // fuzzymatch score for every item.
         // The sortText (which reflects clangd ranking) breaks the tie.
+        // This also prevents VSCode from filtering out any results due to the
+        // differences in how fuzzy filtering is applies, e.g. enable dot-to-arrow
+        // fixes in completion.
         //
         // We also have to mark the list as incomplete to force retrieving new rankings.
         // See https://github.com/microsoft/language-server-protocol/issues/898
         middleware: {
           provideCompletionItem: async (document, position, context, token, next) => {
-            // Get the incomplete identifier before the cursor.
-            let word = document.getWordRangeAtPosition(position);
-            let prefix = word && document.getText(new vscode.Range(word.start, position));
-            
             let list = await next(document, position, context, token);
             let items = (Array.isArray(list) ? list : list.items).map(item => {
+              // Gets the prefix used by vscode when doing fuzzymatch.
+              let prefix = document.getText(new vscode.Range(item.range.start, position))
               if (prefix)
                 item.filterText = prefix + "_" + item.filterText;
               return item;
             })
             return new vscode.CompletionList(items, /*isIncomplete=*/true);
           }
         },
     };
 
   const clangdClient = new ClangdLanguageClient('Clang Language Server',
                                                 serverOptions, clientOptions);
   if (getConfig<boolean>('semanticHighlighting')) {
     const semanticHighlightingFeature =
         new semanticHighlighting.SemanticHighlightingFeature(clangdClient,
                                                              context);
     context.subscriptions.push(
         vscode.Disposable.from(semanticHighlightingFeature));
     clangdClient.registerFeature(semanticHighlightingFeature);
   }
+  clangdClient.registerFeature(new EnableEditsNearCursorFeature);
   console.log('Clang Language Server is now active!');
   context.subscriptions.push(clangdClient.start());
   context.subscriptions.push(vscode.commands.registerCommand(
       'clangd-vscode.switchheadersource', async () => {
         const uri =
             vscode.Uri.file(vscode.window.activeTextEditor.document.fileName);
         if (!uri) {
           return;