clang-rename might sometimes have multiple replacements at one SourceLocation, both trying to perform the same renaming. While this issue should be addressed properly at some point, for now it's fine to prevent clang-rename from printing out the error message to prevent confusion as it works just fine even if the error happens.
Details
- Reviewers
- None
Diff Detail
Event Timeline
clang-rename/RenamingAction.cpp | ||
---|---|---|
74 | Let's consider the following example: struct Point {}; src/a.cpp: include <Point.h> src/b.cpp: include <Point.h> clang-rename -qualified-name Point -new-name Point2 srcs/a.cpp srcs/b.cpp The thing is that clang-rename is trying to modify the same code twice (as in the example) and the return value (Error) of the method Replacements::add doesn't allow us to distinguish two cases: A. conflict (trying to apply different modifications to the same source code) B. (still conflict, but different) (trying to apply the same modification twice). |
clang-rename/RenamingAction.cpp | ||
---|---|---|
74 | But the thing is that it's never the A. case. Unlike other refactorings, clang-rename doesn't introduce any name conflicts, it will only sometimes try to rename something multiple times. |
clang-rename/RenamingAction.cpp | ||
---|---|---|
74 | Yup |
Slightly change wording.
clang-rename/RenamingAction.cpp | ||
---|---|---|
74 | Hence, I'm not sure what your concern is. Can you please elaborate? |
clang-rename/RenamingAction.cpp | ||
---|---|---|
74 | My concerns were about wording, the new version looks good to me. |
clang-rename/RenamingAction.cpp | ||
---|---|---|
74 | Eric actually has a patch for that: https://reviews.llvm.org/D24800 |
Abandoning this, because rL282577, which introduces replacement deduplication, eliminates this issue. Big thanks to Eric!
Did you mean "adding a replacement fails..."?