Newline style changes to Unix-style when file is modified

[ajtribick]

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.

[calebcartwright]

I can reproduce this issue both with the latest 1.x version of rustfmt as well as latest on master

[aloucks]

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.

[aloucks]

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.

rustfmt/src/formatting.rs

Lines 190 to 194 in 494452b

	apply_newline_style(
	config.newline_style(),
	&mut visitor.buffer,
	snippet_provider.entire_snippet(),
	);

[CrendKing]

@topecongiro Is #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.

[calebcartwright]

@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.

[CrendKing]

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]

No worries! It's a bit of a mess and certainly confusing

[ajtribick]

@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?