[PATCH] D71247: [clangd] Rename constructors and destructors in cross-file case

Sam McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Dec 10 09:23:13 PST 2019


sammccall added inline comments.


================
Comment at: clang-tools-extra/clangd/refactor/Rename.cpp:91
   if (const auto *D = SelectedNode->ASTNode.get<Decl>()) {
-    if (D->getLocation() != TokenStartLoc)
-      return {};
+    if (D->getLocation() != TokenStartLoc) {
+      // Destructor->getLocation() points to ~. In this case, TokenStartLoc
----------------
Braindump from an offline conversation...
This seems like an unfortunate place to put a complicated special case and it doesn't generalize well.

The TokenStartLoc check is a bit unfortunate to begin with - it's subject to all the heuristic-token-rewinding problems we've encountered in the past. Its one advantage over plain selectiontree is that it works at the end of the identifier.

Better approach seems to be:
 - we only allow rename targeted at an identifier token
 - there can be at most one identifier touching the location (if there's one before and after, they'd be a single identifier)
 - so find that identifier spelled token using TokenBuffer
 - then look it up as a macro (we get its start location for  free)
 - if that fails, create a selectiontree for the token's range and rename what we find

I don't think there's a better TokenBuffer API than calling spelledTokens() and binary-searching, at the moment.

This touches more code, but is less special-case-y overall. I'd consider putting the getIdentifierTouching(SourceLocation, TokenBuffer, SourceManager) in SourceCode.h


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

https://reviews.llvm.org/D71247





More information about the cfe-commits mailing list