fix(core): match LF regions of mixed-ending files in edit - #45888
Open
skyzhao1223 wants to merge 1 commit into
Open
skyzhao1223 wants to merge 1 commit into
skyzhao1223 wants to merge 1 commit into
Conversation
detectLineEnding treated any file containing a single CRLF as a CRLF file and rewrote the model's oldString to CRLF wholesale. The read tool strips trailing \r, so on mixed-ending files the model reproduced pure LF content that the edit path could then never match, failing with a misleading "Could not find oldString". Treat a file as CRLF only when every newline is a CRLF. Consistent CRLF files behave exactly as before; mixed files match as LF, so LF regions become editable and untouched CRLF lines keep their original endings. Editing the CRLF region of a mixed file still requires follow-up work tracked in anomalyco#45880. Fixes anomalyco#45880
This was referenced Aug 28, 2026
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
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.
Issue for this PR
Closes #45880
Type of change
What does this PR do?
The read tool strips a trailing
\rfrom each line, so the model always sees pure LF content. ButdetectLineEndingin the edit tool classified any file containing a single CRLF as a CRLF file, and then rewrote the model's entireoldStringto CRLF. On a file with mixed endings (one commit from a Windows colleague is enough), oldStrings targeting LF regions could never match and the edit failed with a misleading "Could not find oldString".This is the conservative first step discussed in the issue: treat a file as CRLF only when every newline is a CRLF. Consistently CRLF files behave exactly as before (covered by the existing "preserves BOM and CRLF line endings" test). Mixed-ending files now match as LF, so their LF regions become editable, and untouched CRLF lines keep their original endings byte-for-byte.
Known limitation left open in #45880: editing the CRLF region of a mixed file still won't match. Fixing that properly needs a policy decision (preserve mixed endings vs. normalize to the dominant ending) plus normalized-search span mapping, so I kept it out of this PR.
How did you verify your code works?
New test: editing the LF region of
alpha\nbeta\r\ngamma\nsucceeds and leaves the CRLF line untouched (ALPHA\r\ngamma\n).bun test ./test/tool-edit.test.ts ./test/tool-write.test.ts: 18 pass.bun run typecheckclean, prettier clean.Screenshots / recordings
Not a UI change.
Checklist