Cargo always uses LF line endings for Cargo.lock even if CRLF were present

[jder]

Problem

This PR fixed #2076 but it appears that the functionality has regressed. When cargo writes a lock file, it appears to use LF line endings rather than matching the existing line endings as I would expect.

The test for the above PR writes out a file with CRLFs and then runs generate-lockfile and expects the content on disk to be unchanged. Unfortunately, generate-lockfile tests to see if the lines are equal (which is line-ending agnostic) before writing anything out and so doesn't actually re-write the file. If you edit the test to defeat this optimization then it fails because the lock file is written out with LFs only.

Steps

1. Check out a rust project on Windows with the (default) git setting of autocrlf = true.
2. Note that line endings of your cargo.lock file are CRLF. (git ls-files --eol is a convenient way to do this)
3. Run cargo add $SOMETHING
4. Note that line endings have changed to LF.
5. Try committing the lock file; this will fail if you have the (default) git setting of safecrlf = true

Possible Solution(s)

We could re-establish a check in write_pkg_lockfile to detect and match line endings, as was done in the original PR linked above. I'd be happy to take a crack at this if that sounds good.

Notes

If helpful, git version says: git version 2.41.0.windows.3.

Version

cargo 1.73.0
release: 1.73.0
host: x86_64-pc-windows-msvc
libgit2: 1.6.4 (sys:0.17.2 vendored)
libcurl: 8.2.1-DEV (sys:0.4.65+curl-8.2.1 vendored ssl:Schannel)
os: Windows 10.0.22621 (Windows 11 Enterprise) [64-bit]

[weihanglo]

Interesting! I though it was my first PR to Cargo introducing this regression, but actually it was this one. I feel old 😆.

I can think of two approaches. One is like you said, reintroduce the old trick and rewrite LF to CRLF. The other is having something like an struct Emitter to detect link break format upfront, and uses the same format when constructing the output in memory. The latter seems a bit overkill but can avoid performance loss on Windows or existing CRLF lockfiles.

[weihanglo]

This is a regression for years, but to avoid confusion I am not going to mark it as stable regression.

Thank you for the report!

[jder]

This also seems to happen for Cargo.toml when running cargo add.

[weihanglo]

That one goes with a different code path. We can tackle this first and open a new issue for that. At least I expect by solving this we would have regression test, so we can refactor them altogether later on if needed.

[epage]

The original motivation for this was to not make git think a file changed when it hadn't (#2076).

So long as we only write files out when a change happened, does this matter enough to do something about?

[jder]

Just my 2 cents, but it seems like a pretty bad paper cut that with (what I believe is) the default configuration for git on Windows, cloning most rust projects and having cargo touch a lock file or toml file will result in a cryptic error from git:

$ git clone https://github.com/rust-lang/cargo.git
Cloning into 'cargo'...
remote: Enumerating objects: 122468, done.
remote: Counting objects: 100% (7031/7031), done.
remote: Compressing objects: 100% (604/604), done.
remote: Total 122468 (delta 6578), reused 6669 (delta 6425), pack-reused 115437
Receiving objects: 100% (122468/122468), 41.33 MiB | 32.65 MiB/s, done.
Resolving deltas: 100% (86888/86888), done.
Updating files: 100% (2384/2384), done.
$ cd cargo
$ cargo add rustls
    Updating crates.io index
      Adding rustls v0.21.8 to dependencies.
             Features:
             + log
             + logging
             + tls12
             - dangerous_configuration
             - quic
             - read_buf
             - rustversion
             - secret_extraction
    Updating crates.io index
$ git commit -am "test"
fatal: LF would be replaced by CRLF in Cargo.lock

[ChrisDenton]

With a new install of git with all defaults (installed via winget) I get:

warning: in the working copy of 'Cargo.lock', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'Cargo.toml', LF will be replaced by CRLF the next time Git touches it
[master 377cc5cb2] test
 2 files changed, 63 insertions(+), 2 deletions(-)

[jder]

Thanks! Maybe my system has some different default config for some reason.