Panic when building dependency "yaml" in nightly

[cassiemeharry]

When building a Cargo project that includes yaml = "0.2.0" as a dependency, I'm getting a compiler panic. This is reproducible in a fresh project with no other code, and I've seen it happen in a few different nightly builds (can't use stable due to feature gating).

Cargo output, with RUST_BACKTRACE=1 and --verbose.

$ rustc --version --verbose
rustc 1.1.0-nightly (7a52835c1 2015-05-16) (built 2015-05-15)
binary: rustc
commit-hash: 7a52835c1a6da00dd054c2e934a70a0c231dffd1
commit-date: 2015-05-16
build-date: 2015-05-15
host: x86_64-apple-darwin
release: 1.1.0-nightly

On a side note, Cargo's output makes it look like the bug happens when compiling regex_macros, a sub dependency, but the last line says it's actually compiling yaml. This is slightly confusing.

[cassiemeharry]

Forgot this was still here. Just tested it in the most recent nightly, and while it fails to build, it seems to be due to API changes rather than an ICE:

$ RUST_BACKTRACE=1 multirust run nightly cargo build
   Compiling regex-syntax v0.2.2
   Compiling libc v0.2.6
   Compiling yaml v0.2.0
/Users/nick/.multirust/toolchains/nightly/cargo/registry/src/github.com-88ac128001ac3a9a/yaml-0.2.0/build.rs:3:21: 3:28 error: unresolved import `std::fs::PathExt`. There is no `PathExt` in `std::fs` [E0432]
/Users/nick/.multirust/toolchains/nightly/cargo/registry/src/github.com-88ac128001ac3a9a/yaml-0.2.0/build.rs:3 use std::fs::{File, PathExt};
                                                                                                                                   ^~~~~~~
/Users/nick/.multirust/toolchains/nightly/cargo/registry/src/github.com-88ac128001ac3a9a/yaml-0.2.0/build.rs:3:21: 3:28 help: run `rustc --explain E0432` to see a detailed explanation
error: aborting due to previous error
Build failed, waiting for other jobs to finish...
Could not compile `yaml`.

To learn more, run the command again with --verbose.

$ multirust run nightly rustc --version
rustc 1.8.0-nightly (094c5b0d6 2016-01-31)

I think you can go ahead and take this off of #29249.