rustfmt section might cause issues with git's autocrlf

[epage]

rustfmt's default newline style is unix.

For people using git's autocrlf, this will cause problems. They'll checkout the code with crlf, and rustfmt will change it to lf and things might get sad.

cobalt is where this was first notice.

Two options

• Encourage people to override it to native in rustfmt.tonl
• Tell git / editors to use native for rust
  • .editorconfig
  • .gitattributes

[epage]

Maybe this isn't so bad because git still commits the files with LF?

[CAD97]

By default, this is true (for files Git recognizes as text, i.e. no NUL bytes).

And I think cargo fmt -- --write-mode=diff won't fail anyway, given empirical testing.

While running cargo fmt changes my main.rs from CRLF to LF, cargo fmt -- --write-mode=diff does not fail with CRLF line endings:

Christopher@CAD-A18 MINGW64 /d/Christopher/Documents/Code/Rust/cargo-ghp-upload (use-self)
$ file src/main.rs
src/main.rs: C source, ASCII text, with CRLF line terminators

Christopher@CAD-A18 MINGW64 /d/Christopher/Documents/Code/Rust/cargo-ghp-upload (use-self)
$ cargo fmt -- --write-mode=diff

Christopher@CAD-A18 MINGW64 /d/Christopher/Documents/Code/Rust/cargo-ghp-upload (use-self)
$ echo $?
0

[CAD97]

I've yet to see an editor on Windows (other than Notepad) that messes up when a file has LF line separators.

This is an issue when test files rely on the bytes of a line ending: rust-lang/rust-analyzer#14

In that issue the tests were checking the String output of running a function against the contents of a file, and the LF/CRLF was causing a mismatch. The solution was just to normalize the files on read to match the generated string.

The even better solution would have been to tell Git not to mess with the newlines for those files so certain input files could test behavior when the program was fed LF and CRLF, but we didn't decide to go with that solution.

[Geobert]

We had an issue on Cobalt where rustfmt, changed all the CRLF to LF, changing unchanged file EOL and so they will appear as modified even if we didn't touch them.
We solved this by using .editorconfig and .gitattributes to force everything to LF

[CAD97]

OK, so after paying attention for a while, here's my observations:

• Git by default checks out native-style line endings and commits unix-style.
• rustfmt --write-mode=diff still passes if the only difference is line endings.
• Creating a new file uses native-style line endings.
• Depending on the tool used, line endings which are not what you last checked in may show up as modified (no differences). This occurs at least in the JetBrains family of editors.
• Committing the "changed" file with only line ending differences does not actually show up in the commit.

I think that the best cost-benefit solution is to advise including an .editorconfig file specifying newline style to be Unix. This moves further towards normalizing line endings rather than expecting Git to always be configured correctly. Also, advising people to always run rustfmt before committing, and then the tooling inconsistency disappears.