Mark first block before matching content as changed in line ranges mapping#4997
Mark first block before matching content as changed in line ranges mapping#4997bysiber wants to merge 2 commits into
Conversation
|
Thanks! Could you add a unit test for this behavior and a NEWS entry describing the user-visible change? |
|
Added both — unit test in test_ranges.py (test_first_block_changed) and a CHANGES.md entry under Stable style. The test verifies that changes in the first block before any matching content are correctly included in the adjusted line ranges. |
|
@bysiber Please review the test failures |
themavik
left a comment
There was a problem hiding this comment.
is_changed_block=True for that first LineMapping fixes adjusted_lines when only the leading line differs; test_first_block_changed is the right minimal repro. nit: if a future case has an unchanged prefix that still maps through block.a, add another regression beside the x=10 edit.
|
Hey @bysiber, are you still updating this PR? |
In
_calculate_lines_mappings, when the firstmatching_blocksentry doesn't start at offset 0, the content before it is different between original and modified. This block should be marked asis_changed_block=True, but it's currently markedFalse.What goes wrong
The
adjusted_linesfunction usesis_changed_blockto decide how to remap line ranges:When the first changed block is mislabeled as unchanged, a linear offset is applied instead of block expansion. For example, if the original file has 5 lines changed at the top that become 3 lines after formatting, a
--line-ranges 1-5would compute the new range as(1, 5)via offset instead of the correct(1, 3)via block expansion. The range extends past the actual modified content.The
elsebranch (fori > 0) correctly marks inter-block gaps asis_changed_block=True— this first-block case was just missed.