Added calculateRangesAfterReplaments() to calculate original ranges as well as
newly affacted ranges in the new code.
Details
- Reviewers
klimek djasper - Commits
- rG8b636db8d4c6: Added calculateRangesAfterReplaments() to calculate affacted ranges in the new…
rC273290: Added calculateRangesAfterReplaments() to calculate affacted ranges in the new…
rL273290: Added calculateRangesAfterReplaments() to calculate affacted ranges in the…
Diff Detail
Event Timeline
include/clang/Tooling/Core/Replacement.h | ||
---|---|---|
80 | Can we keep these private for now? | |
245 | Should we make the latter optional? | |
248 | s/Replacemments/Replacements/ | |
253 | I'd call this getShiftedRanges(). | |
254 | const vector&? | |
lib/Tooling/Core/Replacement.cpp | ||
39 | No need for parentheses. | |
334 | Remove " a" | |
335 | Just return the new vector and use a const parameter. | |
358 | Couldn't we implement this using mergeReplacements? Fundamentally:
|
include/clang/Tooling/Core/Replacement.h | ||
---|---|---|
245 | Why would why want to exclude the newly affected ranges? But if replaces overlap with original ranges, do we consider sub-ranges in original ranges being replaced as parts of the shifted ranges in the new code? | |
253 | getShiftedRanges sounds like it's excluding affected ranges of Replaces. I think often time we want both? | |
lib/Tooling/Core/Replacement.cpp | ||
335 | Shall we pass Ranges by value instead since it's gonna be sorted anyway? Also, does it make sense to have calculateChangedRanges() call this? | |
358 | That actually works very well! Thanks! |
Nice :)
include/clang/Tooling/Core/Replacement.h | ||
---|---|---|
62 | Can we just add a lambda that does this to the std::sort operation? I am not sure that this is actually a natural order for all Replacements. | |
69 | Why is this required? | |
lib/Tooling/Core/Replacement.cpp | ||
287 | maybe: std::vector<Range> Result; for (const auto &R: Ranges) { if (Result.empty() || !Result.back().overlapsWith(R)) { Result.push_back(R); } else { unsigned NewEnd = std::max(Result.back.getOffset() + Result.back.getLength(), R.getOffset() + R.getLength()); Result[Result.size() - 1] = Range(Result.back.getOffset(), NewEnd - Result.back.getOffset()); } } | |
319 | I'd probably leave these early exits out. I don't think anyone will ever notice the performance difference. | |
321 | I think you need to do: Ranges = mergeAndSortRanges(Ranges); here |
- Addressed reviewer's comments.
include/clang/Tooling/Core/Replacement.h | ||
---|---|---|
69 | It is used in unit test to test the equality between two ranges. | |
lib/Tooling/Core/Replacement.cpp | ||
287 | Thanks! Just one minor point: we also want to merge ranges R1 and R2 if R1.getOffset() + R1.getLength() == R2.getOffset() For example, if we have R1(1, 1) and R2(2, 1), then we can merge them into R3(1, 2). |
A couple of small comments, otherwise looks good.
lib/Tooling/Core/Replacement.cpp | ||
---|---|---|
284 | I don't think you need "-> bool". | |
285 | or std::tie(LHS.getOffset(), LHS.getLength()) < std::tie(RHS.getOffset(), RHS.getLength())? | |
292 | Maybe pull out: unsigned CurrentEnd = Result.back().getOffset() + Result.back().getLength(); Will probably save a line or two :) |
Can we just add a lambda that does this to the std::sort operation? I am not sure that this is actually a natural order for all Replacements.