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
Event Timeline
clang-rename/USRLocFinder.cpp | ||
---|---|---|
37 | For constructors, we nowadays usually want to take strings by value and then std::move them into the fields. | |
75 | Why startswith as opposed to ==? | |
clang-rename/USRLocFinder.h | ||
32–35 | 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 | 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 | 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 | 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. |
Now that I see this - is there a reason not to use const std::string& for the usr? Also, should we instead use StringRef?