Repository navigation
system/idempotence tests: also assert on line endings - #7233
Draft
matthewhughes934 wants to merge 1 commit into
Draft
matthewhughes934 wants to merge 1 commit into
matthewhughes934 wants to merge 1 commit into
Conversation
1 of 2 tasks
matthewhughes934
force-pushed
the
eol-testing
branch
2 times, most recently
from
November 5, 2026 21:18
2554230 to
cdb119e
Compare
While working on rust-lang#7220 I got curious about how the integration tests handle line endings, specifically CRLF, and it turns out they don't. Given we have features that explicitly add/remove these line endings we should ensure the tests correctly cover this case to avoid regressions. We use `diff::lines` to generate diffs, and this calls `str::lines` under the hood, which strip any trailing `\r\n` or `\n`. So the only way we can tell that line-endings differ is by comparing the two contents, previously we performed this comparison in a way that would ignore if one file had `\r\n` endings and another had `\n` endings. This meant we never actually asserted that we saw the expected line endings. Note: we can only tell the files have differing line endings, not the lines where this occurs. It _could_ be a future improvement to make this more specific, but I think the approach is reasonable since there aren't any tests (or really any use case) for mixed line-endings in a single file. This reflects the behaviour of how we report such errors with e.g. `emitter::diff::DiffEmitter::emit_formatted_file` This required updating some test files that used `newline_style=Windows` but never actually added those line endings in the corresponding `target`. In these cases carriage returns are added to the `target` files, but not the `source` ones so these tests also assert that we do indeed convert the line endings. The files `tests/{target,source}/configs/enum_discrim_align_threshold/40.rs` had CRLF line endings, but not corresponding `newline_style` option and the feature does not depend on line endings, so these were converted back to used Unix line endings
matthewhughes934
force-pushed
the
eol-testing
branch
from
November 5, 2026 21:22
cdb119e to
99446fb
Compare
Contributor
Author
|
🫠 wrestling with line endings + EDIT: why is |
This branch has not been deployed
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.
While working on #7220 I got curious about how the integration tests handle line endings, specifically CRLF, and it turns out they don't. Given we have features that explicitly add/remove these line endings we should ensure the tests correctly cover this case to avoid regressions.
We use
diff::linesto generate diffs, and this callsstr::linesunder the hood, which strip any trailing\r\nor\n. So the only way we can tell that line-endings differ is by comparing the two contents, previously we performed this comparison in a way that would ignore if one file had\r\nendings and another had\nendings. This meant we never actually asserted that we saw the expected line endings.Note: we can only tell the files have differing line endings, not the lines where this occurs. It could be a future improvement to make this more specific, but I think the approach is reasonable since there aren't any tests (or really any use case) for mixed line-endings in a single file. This reflects the behaviour of how we report such errors with e.g.
emitter::diff::DiffEmitter::emit_formatted_fileThis required updating some test files that used
newline_style=Windowsbut never actually added those line endings in the correspondingtarget. In these cases carriage returns are added to thetargetfiles, but not thesourceones so these tests also assert that we do indeed convert the line endings.The files
tests/{target,source}/configs/enum_discrim_align_threshold/40.rshad CRLF line endings, but not correspondingnewline_styleoption and the feature does not depend on line endings, so these were converted back to used Unix line endingsNB: this diff might not be very helpful to view in the GitHub UI, since it doesn't show line ending changes