[clangd][vscode] Surface the error when applying tweaks fails

[hokein]

Summary

The current behavior for a failed request is just to log it in the
output panel. When applyTweak fails for whatever reason, users usually don't get
informed (unless they open the output panel and dig the log).

this patch is to surface these errors by prompting up a message diag.

[ilya-biryukov]

Surfacing errors to the users in those cases is definitely something we need to do, thanks!
How do they look in practice? In particular, should we add more context information (either in clangd or in the VSCode extension) to those errors, now that we know they are shown to the users?
Something like Failed to apply a fix: input range is invalid vs input range is invalid.

[hokein]

In D66211#1629112, @ilya-biryukov wrote:

How do they look in practice? In particular, should we add more context information (either in clangd or in the VSCode extension) to those errors, now that we know they are shown to the users?
Something like Failed to apply a fix: input range is invalid vs input range is invalid.

I don't have a very strong preference on adding more context, the current messages seem good enough to me, something like:

• "edits were not applied: <reason>"
• "Could not expand type of lambda expression:"
• "Could not obtain range of the 'else' branch. Macros?"

[ilya-biryukov]

Thanks for providing examples of error messages, also agree they look fine.
If we find bad error messages later, we could revisit the presentation strategy.
LGTM

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

109

Is this how default implementation behaves? Is there a way to call into it instead of re-implementing?
If so, it would be nice to do so. If not, I'm also ok if we keep it.

[hokein]

avoid re-implementing of the method.

[hokein]

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

109

manage to figure out a way to do it. We have to define a subclass of LanguageClient, and override logFailedRequest.

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

const clientOptions: vscodelc.LanguageClientOptions = {
         },
         initializationOptions: { clangdFileStatus: true },
         // Do not switch to output window when clangd returns output
         revealOutputChannelOn: vscodelc.RevealOutputChannelOn.Never
     };
 
   const clangdClient = new vscodelc.LanguageClient(
       'Clang Language Server', serverOptions, clientOptions);
+
+  // We override the default implementation for failed requests. The default
+  // behavior is just to log failures in the output panel, however output panel
+  // is designed for extension debugging purpose, normal users will not open it,
+  // thus when the failure occurs, normal users doesn't know that.
+  //
+  // For user-interactive operations (e.g. applyFixIt, applyTweaks), we will prompt
+  // up the failure to users.
+  clangdClient.logFailedRequest =
+      (rpcReply: vscodelc.RPCMessageType, error: any) => {
+        if (error instanceof vscodelc.ResponseError &&
+            rpcReply.method === "workspace/executeCommand")
+          vscode.window.showErrorMessage(error.message);
+
+        // Keep the default behavior.
+        if (error instanceof vscodelc.ResponseError &&
+            error.code === vscodelc.ErrorCodes.RequestCancelled)
+          return;
+        clangdClient.error(`Request ${rpcReply.method} failed.`, error);
+      };
   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;