Attempt to show correct newline style in json emitter

[calebcartwright]

The json emit mode currently always appends unix style line endings to the end of the output snippets (#4262 and #4259) .

It may not be possible to provide both the original and expected trailing line endings given our current solution for building the diff between original and expected formatting. rustfmt currently leverages the diff crate which results in the dropping of the trailing newline information (Refs #3850 (comment))

We could technically determine the correct newline style to apply for the expected formatting even with the current make_diff approach, perhaps by leveraging some of the newline functions like effective_newline_style. However, the challenges with original contents would pose problems for a scenario where the only changes rustfmt would make are newline style conversions.

rustfmt/src/formatting/newline_style.rs

Lines 26 to 36 in e208a39

	fn effective_newline_style(
	newline_style: NewlineStyle,
	raw_input_text: &str,
	) -> EffectiveNewlineStyle {
	match newline_style {
	NewlineStyle::Auto => auto_detect_newline_style(raw_input_text),
	NewlineStyle::Native => native_newline_style(),
	NewlineStyle::Windows => EffectiveNewlineStyle::Windows,
	NewlineStyle::Unix => EffectiveNewlineStyle::Unix,
	}
	}

[vineetred]

@calebcartwright I'm confused as to what the issue is. Is it that even non-UNIX machines get UNIX style newlines?

[calebcartwright]

@vineetred - when running rustfmt in the default emit mode (reformatting the input files for example), rustfmt will apply newline style based on the configured value of the newline_style configuration option.

So if I have some file that has Windows style line endings:

$ cat -e src/lib.rs 
fn foo() {println!("bar");^M$
}^M$

And I run

rustfmt src/lib.rs --config newline_style=Windows

The formatted output rustfmt emits will indeed maintain Windows style line endings:

$ rustfmt src/lib.rs --config newline_style=Windows
$ cat -e src/lib.rs
fn foo() {^M$
    println!("bar");^M$
}^M$

However, if you run rustfmt with the json emit mode against the original input, you'll see the line endings are always represented in unix style regardless of the configured newline_style value

$ rustfmt src/lib.rs --emit json  --config newline_style=Windows 
[{"name":"/home/caleb/dev/rustfmt-sandbox/json-newline/src/lib.rs","mismatches":[{"original_begin_line":1,"original_end_line":1,"expected_begin_line":1,"expected_end_line":2,"original":"fn foo() {println!(\"bar\");\n","expected":"fn foo() {\n    println!(\"bar\");\n"}]}]

Similarly, (once the formatting fix is applied) you can also observe the --check emit mode verifying newline style. However, the json emit mode doesn't catch the newline style issue that default (files) and check emit modes do

$ cat -e src/lib.rs 
fn foo() {println!("bar");^M$
}^M$

$ rustfmt src/lib.rs --check  --config newline_style=Windows
$ echo $?
0
$ rustfmt src/lib.rs --check  --config newline_style=Unix
Incorrect newline style in /home/caleb/dev/rustfmt-sandbox/json-newline/src/lib.rs
$ echo $?
1
$ rustfmt src/lib.rs --emit json  --config newline_style=Unix
[]
$ echo $?
0

[vineetred]

So basically, rustfmt knows what the correct newline configuration is -- as made evident by running rustfmt with the --check flag. However, this does not translate to it being shown properly in the JSON file. Is this right?