[PATCH] D36156: [rename] Introduce symbol occurrences
Manuel Klimek via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Aug 2 03:00:27 PDT 2017
klimek added inline comments.
================
Comment at: include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h:32
+/// a macro expansion.
+class SymbolOccurrence {
+public:
----------------
I understand the exact vs. non-exact idea, but can you expand a bit on how Obj-C code looks where a rename needs to touch more than one location? (I have no idea about Obj-C unfortunately)
================
Comment at: include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h:50
+ ///
+ /// The user will have to fixup their code manually after performing such a
+ /// rename.
----------------
Nit: s/fixup/fix/?
================
Comment at: include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h:65-68
+ ArrayRef<SourceLocation> getNameLocations() const { return Locations; }
+ ArrayRef<unsigned> getNameLengths() const {
+ return llvm::makeArrayRef(NameLengths, Locations.size());
+ }
----------------
Any reason not to return ranges instead here?
================
Comment at: include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h:72-73
+ OccurrenceKind Kind;
+ ArrayRef<SourceLocation> Locations;
+ const unsigned *NameLengths;
+};
----------------
Can we store ranges instead?
================
Comment at: include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h:78
+/// unit.
+class SymbolOccurrences {
+public:
----------------
Why can't we put all data in SymbolOccurrence and just use a normal container here?
Repository:
rL LLVM
https://reviews.llvm.org/D36156
More information about the cfe-commits
mailing list