Skip to content

Commit bc79daf

Browse files
committed
FixItApplier: Non-empty insertions can conflict with other edits
1 parent 94f6ec8 commit bc79daf

File tree

2 files changed

+10
-3
lines changed

2 files changed

+10
-3
lines changed

Sources/SwiftIDEUtils/FixItApplier.swift

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -107,7 +107,15 @@ public enum FixItApplier {
107107
return edit == remainingEdit
108108
}
109109

110-
return remainingEdit.range.overlaps(edit.range)
110+
// Edits conflict in the following cases:
111+
//
112+
// - Their ranges have a common element.
113+
// - One's range is empty and its lower bound is strictly within the
114+
// other's range. So 0..<2 also conflicts with 1..<1, but not with
115+
// 0..<0 or 2..<2.
116+
//
117+
return edit.endUtf8Offset > remainingEdit.startUtf8Offset
118+
&& edit.startUtf8Offset < remainingEdit.endUtf8Offset
111119
}
112120

113121
guard !shouldDropRemainingEdit() else {

Tests/SwiftIDEUtilsTest/FixItApplierTests.swift

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -232,9 +232,8 @@ class FixItApplierApplyEditsTests: XCTestCase {
232232
.init(range: 0..<5, replacement: "_"), // Replacement
233233
.init(range: 2..<2, replacement: "a"), // Insertion
234234
],
235-
// FIXME: This behavior where these edits are not considered overlapping doesn't feel desirable
236235
outputs: [
237-
.init(oneOf: "_x = 1", "_ a= 1")
236+
.init(oneOf: "_ = 1", "vaar x = 1")
238237
]
239238
)
240239
}

0 commit comments

Comments
 (0)