rustfmt
rustfmt copied to clipboard
rust-lang
Newline style changes to Unix-style when file is modified
On Windows, using the default newline style (either without rustfmt.toml or by explicitly setting newline_style="Auto":
- leaves the newlines intact if the file does not have any formatting issues (ok, expected)
- saves modified files with Unix-style endings, even when all line-breaks in the input file are CRLF.
I would expect that in such cases the "Auto" value would use the line-break style inferred from examining the file.
Version used: rustfmt 1.4.11-stable (9eb4b564 2020-01-29)
as invoked via the cargo fmt command, version cargo 1.42.0 (86334295e 2020-01-31)
It's possible to work around this by forcing "Native" style in the rustfmt.toml but the default behaviour results in a mixture of line-ending styles throughout the project and triggers git line-ending conversion warnings.
I can reproduce this issue both with the latest 1.x version of rustfmt as well as latest on master
How long has this been an issue? I recall there was a change to newline handling a while back that broke a bunch of CI, but I thought that was fixed. I can see in the history that there were a lot of changes about a year ago:
https://github.com/rust-lang/rustfmt/commits/master/src/formatting/newline_style.rs
Forcing Native as a work-around is extremely unfortunate because that breaks anyone on Windows that has git configured to use LF.
The content returned by snippet_provider.entire_snippet() is used to check if CRLF exists when using Auto. It looks like, at least on master, that input now normalized to only contain \n prior to the check . As far as I can tell, this is happening when the SourceMap loads the file and eventually calls SourceFile::new.
https://github.com/rust-lang/rustfmt/blob/494452b142fd54800d215cecc971302b3e885b7b/src/formatting.rs#L190-L194
@topecongiro Is https://github.com/rust-lang/rustfmt/pull/4236 supposed to fix this? I can still reproduce the issue with cargo-fmt 1.4.38 nightly. "Native" is still needed to have CRLF.
@CrendKing I know it's not overtly obvious, but #4236 was merged into a different, experimental branch of rustfmt that's unrelated to the version of rustfmt that's actually shipped and supported. When you see issues or PRs that either have milestones pointing to a newer version of rustfmt, like the 2.0 milestone on this issue, or labels mentioning that a backport is pending, that means it hasn't been released/made available.
Oh I'm sorry. I saw it was merged into "master" and has been 2 years, thus assumed it's released. Now I see it's scheduled for 2.0. Thanks.
@calebcartwright - would it be worth raising an issue to backport the fix to the released version? Or is the architecture too different between 2.0 and 1.4.x to make it worthwhile?
@calebcartwright - would it be worth raising an issue to backport the fix to the released version? Or is the architecture too different between 2.0 and 1.4.x to make it worthwhile?
No, I don't want to add a new issue. If someone wants to attempt to backport #4236 that'd be great, but I can't really speak to the effort involved. It could be as simple as a clean cherry pick of the merged commit(s), or, that implementation could touch/depend on portions of the codebase that had diverged significantly and may require a separate implementation against the current master branch.
I will reopen this issue though to hopefully make the current status more clear
This is still an issue as of rustfmt 1.8.0-nightly (8405332bdf 2025-05-12). Has the fix actually still not made its way into a release 4 years later?
