Cannot run `cargo doc` on Windows; Linux works fine

[nukep]

Whenever I run cargo doc on any project, cargo panics with the error:

$ cargo new test
$ cd test
$ cargo doc
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', C:\bot\slave\nightly-dist-rustc-win-64\build\src\libcore\option.rs:362

If cargo doc is run with RUST_BACKTRACE=1, it outputs a not-so-useful backtrace on Windows:

$ RUST_BACKTRACE=1 cargo doc
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', C:\bot\slave\nightly-dist-rustc-win-64\build\src\libcore\option.r
s:362
stack backtrace:
   1:           0x7f4684 - main
   2:           0x80ea89 - main
   3:           0x7655a7 - main
   4:           0x765d3a - main
   5:           0x80e52a - main
   6:           0x823e99 - main
   7:           0x821191 - main
   8:           0x5a4466 - main
   9:           0x5a479c - main
  10:           0x5a4a2e - main
  11:           0x4f5309 - main
  12:           0x464403 - main
  13:           0x5321d8 - main
  14:           0x55a65b - main
  15:           0x4d4cfc - main
  16:           0x4ce197 - main
  17:           0x4ca2cb - main
  18:           0x4e3287 - main
  19:           0x41db3e - main
  20:           0x40936d - main
  21:           0x4044ae - main
  22:           0x40212a
  23:           0x810e1c - main
  24:           0x810df9 - main
  25:           0x80f36c - main
  26:           0x4013b5
  27:           0x4014e8
  28:     0x7ffd672316ad - BaseThreadInitThunk

This will only fail on Windows. Running cargo doc on Linux will successfully generate the rustdocs without panicking.

cargo test and cargo build both work on Windows and Linux without panicking.

cargo --version:

• Windows: cargo 0.0.1-pre-nightly (dd7c7bd 2015-03-04) (built 2015-03-05)
• Linux: cargo 0.0.1-pre-nightly (dd7c7bd 2015-03-04) (built 2015-03-04)

Because I had some old Rust installers laying around, I tested the issue with older versions. It fails on a58ffd7, but it works without panicking on 43755c0. This leads me to believe that the regression was introduced between these two commits.

[alexcrichton]

Hm I can't seem to reproduce this with the Cargo built on 3/9, does this still reproduce for you?

[nukep]

Recompiling Cargo with the 2015-03-09 rustc. I get the same issue.

cargo --version

• Windows: cargo 0.0.1-pre (66849de 2015-03-10) (built 2015-03-10)

Because it might be useful to know, I'm running x86-64 builds as well.

I'll work on getting a meaningful backtrace.

[alexcrichton]

I've found gdb better at getting backtraces, but I've also found it's more reliable on 32-bit than 64-bit, but times may change!

[nukep]

Just tested on 32-bit. It gives the same issue.

[nukep]

thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', C:/bot/slave/nightly-dist-rustc-win-64/build/src/libcore\option.rs:362
[Inferior 1 (process 2568) exited with code 0145]
(gdb) bt
No stack.

:(

Is cargo not compiled with debug symbols by default? Is there any way to get them?

EDIT: Whoops, I didn't notice that the process exited.

[nukep]

Okay, gdb says the issue occurs on this line: https://github.com/rust-lang/cargo/blob/master/src/cargo/sources/path.rs#L102

Using some good ol' println-based debugging, the values of p and root are:

p: "C:\src\rust\cargo-test\test\.gitignore"
root: "c:\src\rust\cargo-test\test"

[nukep]

I removed .gitignore to see if it had anything to do with the prefixed dot. Nope, same problem.

p: "C:\src\rust\cargo-test\test\Cargo.toml"
root: "c:\src\rust\cargo-test\test"

[nukep]

use std::path::Path;
fn main() {
    let p = Path::new(r"C:\src\rust\cargo-test\test\Cargo.toml");
    println!("{:?}", p.relative_from(r"C:\src\rust\cargo-test\test"));
    println!("{:?}", p.relative_from(r"c:\src\rust\cargo-test\test"));
}

Some("Cargo.toml")
None

A difference in case is throwing it off. Is this a bug in Rust or in Cargo, then? :)

[alexcrichton]

Ah, this sounds like a Rust bug in that case, could you open an issue about it?

[alexcrichton]

Thanks for investigating!