Cargo does not handle non-UTF8 gitignores gracefully #11311
Labels
A-diagnostics
Area: Error and warning messages generated by Cargo itself.
C-bug
Category: bug
Command-init
E-easy
Experience: Easy
Problem
When attempting to run
cargo init --bin .
on an existing Git repository in cargo 1.64, cargo failed with the somewhat crypticIn that version of cargo, that unwrap corresponds to this line, which in main is currently line 600.
It appears that the cause is that when a
.gitignore
is present that is not UTF-8, Cargo assumes byunwrap
that it must be UTF-8, and panics because the assumption does not hold. In this case, the existing Git repository had a.gitignore
that had been checked in by a Windows user that had accidentally been checked in as UTF-16LE with BOMs and CRLF terminators! While the presence of such.gitignore
s is definitely a user problem (git
doesn't seem to work with such files), the error handling oncargo
's side should probably be more graceful.Steps
.gitignore
that is not valid UTF-8, for instanceprintf '\xFF\xFE' > .gitignore
cargo init
Possible Solution(s)
As previously mentioned, the bug is an
unwrap
that should be a user-facing error, socargo
should IMO be returning an error to the user here to state that their existing ignore file is badly formed.cargo
could try to rectify the problem but this feels like scope creep.Notes
No response
Version
The text was updated successfully, but these errors were encountered: