x86_64-pc-windows-msvc build failing: expected `src/lib.rs` to start with:

[klensy]

building 2ced82c failed:

error: failed to run custom build command for `rustc_apfloat v0.2.0+llvm-462a31f5a5ab (G:\projs\rustc_apfloat)`

Caused by:
  process didn't exit successfully: `G:\projs\rustc_apfloat\target\debug\build\rustc_apfloat-cd007fccae510ac7\build-scri
pt-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs

  --- stderr

  expected `src/lib.rs` to start with:

  //! Port of LLVM's APFloat software floating-point implementation from the
  //! following C++ sources (please update commit hash when backporting):
  //! https://github.com/llvm/llvm-project/commit/

  thread 'main' panicked at 'failed to validate `src/lib.rs`'s commit hash (see above)', build.rs:32:13
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Probably line ending mismatch?

Reproduce: clone master branch, build with cargo build on x86_64-pc-windows-msvc.

[wesleywiser]

I believe this depends on the setting of git's core.autocrlf option. I have core.autocrlf=false and it builds fine for me on x86_64-pc-windows-msvc.

[klensy]

$ git config  --system --get core.autocrlf
true

Yeah, but still not nice.

[wesleywiser]

For sure! Just leaving that detail since I couldn't replicate it locally before messing with that setting.

[eddyb]

I don't understand why the official Git installer suggests core.autocrlf = true, it's pretty disruptive IME.
(and as of Windows 10, I don't even think notepad.exe, the last thing in existence to care about \r\n, even does make a distinction anymore, between \r\n and \n)

Quick check so we know whether a republish is needed:

$ cd $(mktemp -d) # (optional: switching to a fresh temp dir)
$ cargo new foo
     Created binary (application) `foo` package
$ cd foo
$ cargo add rustc_apfloat
    Updating crates.io index
      Adding rustc_apfloat v0.2.0 to dependencies.
    Updating crates.io index
$ cargo check
   Compiling rustc_apfloat v0.2.0+llvm-462a31f5a5ab
    Checking smallvec v1.11.0
    Checking bitflags v1.3.2
    Checking foo v0.1.0 (/tmp/tmp.t2YVLdMuNl/foo)
    Finished dev [unoptimized + debuginfo] target(s) in 0.74s

@klensy can you try doing this on your system and seeing if it fails as well?
AIUI Cargo's behavior shouldn't depend on your core.autocrlf setting, but I could be wrong.

[klensy]

@eddyb No fail in that case.

[eddyb]

Thanks! So that shouldn't stop anyone from using the crate as a dependency, it only impacts manual checkouts of the repo (we should still fix it ofc, just less scary than the alternative).

[mati865]

I don't understand why the official Git installer suggests core.autocrlf = true, it's pretty disruptive IME.

IIRC some old Visual Studio versions didn't work when project files (not source code) had LF end of line character. Why the installer still selects worst possible option remains a mystery.

Maybe it would be enough to add notice to README saying this project will not build with misconfigured Git?