Match an anchor across mixed line endings - #787
Merged
Conversation
The anchor is normalised to the file's dominant line ending before the search. That is right for writing the replacement and wrong for finding what to replace: Matches compared byte for byte, so a literal whose own lines use the other ending was not the expression the test run sent, and the snapshot could not be patched at all. Mixed endings inside one file are ordinary rather than exotic - a merge, an editor that only normalises what it touches, a generated region. The failure is also silent in the unhelpful direction: the report is that the previous expected expression was not found, which reads as "the source moved on", so re-running the test produces the same message forever. Keep the ordinal compare as the fast path and fall back to comparing with newlines normalised on both sides. The splice still uses the argument's real span, so nothing about what gets written changes.
…-anchor # Conflicts: # src/DiffEngine.Tests/InlinePatcherTests.cs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The anchor is normalised to the file's dominant line ending before the search.
That is right for writing the replacement and wrong for finding what to replace:
Matches compared byte for byte, so a literal whose own lines use the other
ending was not the expression the test run sent, and the snapshot could not be
patched at all.
Mixed endings inside one file are ordinary rather than exotic - a merge, an
editor that only normalises what it touches, a generated region. The failure is
also silent in the unhelpful direction: the report is that the previous expected
expression was not found, which reads as "the source moved on", so re-running
the test produces the same message forever.
Keep the ordinal compare as the fast path and fall back to comparing with
newlines normalised on both sides. The splice still uses the argument's real
span, so nothing about what gets written changes.