This more general check could have prevented the specific problem
"getSourceOrder() == -1" guards.
Details
- Reviewers
klimek cfe-commits - Commits
- rG1d48e5015955: clang-rename: check that the source location we find actually has the old name
rCTE269402: clang-rename: check that the source location we find actually has the old name
rL269402: clang-rename: check that the source location we find actually has the old name
Diff Detail
- Repository
- rL LLVM
Event Timeline
clang-rename/USRLocFinder.cpp | ||
---|---|---|
37 ↗ | (On Diff #57077) | For constructors, we nowadays usually want to take strings by value and then std::move them into the fields. |
75 ↗ | (On Diff #57077) | Why startswith as opposed to ==? |
clang-rename/USRLocFinder.h | ||
30–33 ↗ | (On Diff #57077) | Now that I see this - is there a reason not to use const std::string& for the usr? Also, should we instead use StringRef? |
clang-rename/USRLocFinder.cpp | ||
---|---|---|
75 ↗ | (On Diff #57077) | The source range is "foo(0)", the old name is "foo". Or is there a way to get the range of the name part of the initializer, without the "(0)" part? I'll fix the rest, those are easy. :-) |
clang-rename/USRLocFinder.cpp | ||
---|---|---|
75 ↗ | (On Diff #57077) | Yep, if you want to get an identifier, you just get the code for the range getLocation(), getLocation() (note that ranges are inclusive token-ranges by default) |
Got rid of startswith() and now using StringRef everywhere instead of a mix of std::string, const std::string and const std::string&.
lg
clang-rename/USRLocFinder.cpp | ||
---|---|---|
126–128 ↗ | (On Diff #57140) | Usually storing StringRefs in the class is dangerous, but as this is defined in the .cpp file and only used as part of the function, that's probably fine. |