Give rustfmt a hint about stdin input

[ytmimi]

trafficstars

When formatting text via stdin rustfmt didn't have a way to ignore stdin input.

Now, when passing input to rustfmt via stdin one can also provide the --stdin-file-hint option to inform rustfmt that the input is actually from the hinted at file. rustfmt now uses this hint to determine if it can ignore formatting stdin and immediately echo the input back to the user.

Note: This option can only be passed when formatting files via stdin, and is intended for text editor plugins that call rustfmt by passing input via stdin (e.g. rust-analyzer).

[ytmimi]

Looks like the "stable" tests are failing because the ignore list can't be set. I'll add the #[nightly_only_test] to the relevant tests.

~~Also looks like some issues with windows paths.~~ Edit: The issue does not seem to be related to windows paths see comment below

[ytmimi]

Looking at (i686-pc-windows-gnu, nightly) logs (but all windows logs should be similar) I added some println! macros to help me debug what's going on. I'm scratching my head because the strings should be the same but the comparison is failing on windows, but succeeding on linux/mac.

Heres' an example of one of the logs

---- rustfmt_stdin_formatting::changes_are_output_to_stdout stdout ----
expect: fn main() {
    println!("hello world!");
}

stdout: fn main() {
    println!("hello world!");
}

stderr: 
thread 'rustfmt_stdin_formatting::changes_are_output_to_stdout' panicked at 'assertion failed: stdout == expected_output', tests\rustfmt\main.rs:212:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Edit:

If you compare the expect value with the stdout value in a python REPL it shows that they're the same, so now I'm really confused 🙃

>>> expect = """
... fn main() {
...     println!("hello world!");
... }
... """
>>> stdout = """
... fn main() {
...     println!("hello world!");
... }
... """
>>> expect == stdout
True

[calebcartwright]

I'm scratching my head because the strings should be the same but the comparison is failing on windows, but succeeding on linux/mac.

Haven't looked at this in detail but this type of thing often hints at line endings

[ytmimi]

Haven't looked at this in detail but this type of thing often hints at line endings

Ahh I didn't even consider that as a possible issue. I'll investigate that!

[ytmimi]

@calebcartwright you were right. It turns out it was a line ending issue. For the tests that were giving me trouble I decided to pass them the newline_style=Unix config option to not have to worry about the line endings.

No rush on the review!