[PATCH] D91134: [clangd] Abort rename when given the same name

Haojian Wu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Nov 10 10:57:20 PST 2020


hokein added inline comments.


================
Comment at: clang-tools-extra/clangd/refactor/Rename.cpp:218
+    case ReasonToReject::SameName:
+      return "new name should differ from the old name";
     }
----------------
sammccall wrote:
> hokein wrote:
> > returning an error seems to be an interesting idea, thinking more about that, it might be better than just returning an empty workspaceEdit silently without noticing user.
> > 
> We don't know what the user's intent was here - it's at least somewhat likely they changed their mind about the operation but hit "enter" instead of "escape". So a message describing the situation "new name is the same as the old name" would be more appropriate than suggesting a correction.
> 
> But I'm wondering whether this error message actually helps (vs "succeeding" with no edits). Is it actionable? What's the scenario where the user:
> a) doesn't already know that the name is the same, and
> b) will take some action as a result (rather than leave the name unchanged)
> 
>  a message describing the situation "new name is the same as the old name" would be more appropriate than suggesting a correction.

SG.

In an ideal world, I'd expect we emit a non-error message to inform that there is nothing happen for the rename, but LSP doesn't have such option :(

The behavior of editors are varied on this case, e.g.
- VSCode just succeeds with no edits;
- our internal editor emits a message like "nothing to rename";


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91134



More information about the cfe-commits mailing list