[Stable] ICE on Windows 7 when compiling dependencies

[jjpe]

UPDATE 2:
I just talked over this issue on internals and it strongly looks like this ICE is triggered because the code was effectively on a network drive. I moved the project to an internal disk, and now it compiles fine.
Still, I'd rather not close this issue just yet, as it would be nice to be able to compile from a network drive without ICE. This bug also seems related to this one, and is perhaps even a duplicate.

UPDATE: I just tried this with stable rustc 1.20.0 (f3d6973f4 2017-08-27) running on i686-pc-windows-msvc, and get the same result as with nightly.

I'm trying to compile a project for work on Windows 7 using rustc 1.22.0-nightly (c6884b12d 2017-09-30), but compilation fails when trying to build the project's dependencies.
Interesting to note is that the same rustc version on OS X has no issues with the same project.

The log output follows:

F:\quip (master)
λ cargo run --bin sxi
warning: could not canonicalize path: 'F:\quip'
warning: could not canonicalize path: 'F:\quip'
warning: could not canonicalize path: 'F:\'
   Compiling kernel32-sys v0.2.2
error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.22.0-nightly (c6884b12d 2017-09-30) running on i686-pc-windows-msvc

note: run with `RUST_BACKTRACE=1` for a backtrace

thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 1, message: "Incorrect function." } }', src\libcore\result.rs:906:4
stack backtrace:
   0: 0x62d9131d - std::panicking::Location::column::h9895b0760262a28a
   1: 0x62d90fba - std::panicking::Location::column::h9895b0760262a28a
   2: 0x62d91868 - std::panicking::rust_panic_with_hook::h8f20d66610e2b881
   3: 0x62d916de - std::panicking::begin_panic_fmt::hb90e383f78c9754f
   4: 0x62d91667 - std::panicking::begin_panic_fmt::hb90e383f78c9754f
   5: 0x62d915b9 - rust_begin_unwind
   6: 0x62da430a - core::panicking::panic_fmt::hf1b6bd69ee550bb9
   7: 0x5c586a14 - rustc_metadata::cstore::CrateMetadata::needs_panic_runtime::h066b1941f56c69e2
   8: 0x5c66682b - rustc_metadata::locator::Context::report_errs::he94b06f72750cbc6
   9: 0x5c65b93f - rustc_metadata::creader::CrateLoader::new::h948973d8362524be
  10: 0x5c657bef - rustc_metadata::creader::CrateLoader::new::h948973d8362524be
  11: 0x5c660ca2 - <rustc_metadata::creader::CrateLoader<'a> as rustc::middle::cstore::CrateLoader>::process_item::h8732ec1d24fcb8e2
  12: 0x5cb69b45 - rustc_resolve::build_reduced_graph::<impl rustc_resolve::ToNameBinding<'a> for (rustc::hir::def::Def, rustc::ty::Visibility, syntax_pos::span_encoding::Span, syntax_pos::hygiene::Mark)>::to_name_binding::hdcec3f8b36125949
  13: 0x5cb70fa6 - <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as syntax::visit::Visitor<'a>>::visit_item::hf1aa69c66ee40100
  14: 0x5cb711cc - <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as syntax::visit::Visitor<'a>>::visit_item::hf1aa69c66ee40100
  15: 0x5cb61b8a - rustc_resolve::macros::<impl syntax::ext::base::Resolver for rustc_resolve::Resolver<'a>>::visit_expansion::h1eebd66536c4d25a
  16: 0x62a49a30 - syntax::ext::expand::MacroExpander::expand_crate::h7773bd6ef2621edf
  17: 0x62a3f949 - syntax::ext::expand::MacroExpander::expand_crate::h7773bd6ef2621edf
  18: 0x62a3f3c7 - syntax::ext::expand::MacroExpander::expand_crate::h7773bd6ef2621edf
  19: 0x63d4b353 - rustc_driver::driver::count_nodes::h39504b0a4a68bcf8
  20: 0x63d468ef - rustc_driver::driver::count_nodes::h39504b0a4a68bcf8
  21: 0x63d3e246 - rustc_driver::driver::compile_input::h9417596b5d9e2ea9
  22: 0x63d5e975 - rustc_driver::run_compiler::hf870ea00b3ee6606
  23: 0x63c756cb - <unknown>
  24: 0x62d9899b - _rust_maybe_catch_panic
  25: 0x63cae93f - <rustc_driver::derive_registrar::Finder as rustc::hir::itemlikevisit::ItemLikeVisitor<'v>>::visit_impl_item::h8a468c2ea6f8f76e
  26: 0x62d8f67c - std::sys::imp::thread::Thread::new::h08d4b413205a3a97
  27: 0x76923c44 - BaseThreadInitThunk
  28: 0x76e037f4 - RtlInitializeExceptionChain

error: Could not compile `kernel32-sys`.

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

[parkovski]

The canonicalize code is similar to libuv but a couple flags are different - I suspect the problem has to do with those flags, but I'll need to set up a network drive to test it.

[parkovski]

I've been unable to repro this on Windows 10 - wrote a test program that canonicalizes a network path and tried running it through a symlink, hard link, .bat script, and various different startup args. All work for me. I can also build a project on a network drive with my local cargo, so whatever is causing this must have been fixed in Win10.

The one exception is if I open an admin shell, I lose the network drive. I also can't create a project on the remote drive - it's mapped onto my Mac, and it seems you can't create dot files with the flags Cargo is using (fails at trying to create .gitignore). But if I create the project with the macOS Cargo, I can build it with Windows cargo.

I know a bunch of system path handling functions were changed in Win10 to allow long paths. Canonicalize calls CreateFile and GetFinalPathNameByHandle and neither of those should have issues with network paths. Unfortunately I'm kind of stuck if I can't repro this. I'd try setting a breakpoint in the canonicalize function (libstd/sys/windows/fs.rs) and check the return values, paths going in and out, and GetLastError() for both of those functions I mentioned.

[dvtomas]

The same has happened to me. I am using an official MS VirtualBox trial image downloaded from here, combination IE11 on Win7 (x86)/VirtualBox. When building a project on a VirtualBox shared folder, I get this:

D:\projects\kzvcore>cargo test --jobs 1 --all
warning: could not canonicalize path: 'D:\projects\kzvcore'
warning: could not canonicalize path: 'D:\projects\kzvcore'
warning: could not canonicalize path: 'D:\projects'
warning: could not canonicalize path: 'D:\'
   Compiling owning_ref v0.3.3
error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/m
aster/CONTRIBUTING.md#bug-reports

note: rustc 1.23.0 (766bd11c8 2018-01-01) running on i686-pc-windows-msvc

note: run with `RUST_BACKTRACE=1` for a backtrace

thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: Error {
 repr: Os { code: 1, message: "Incorrect function." } }', src\libcore\result.rs:
906:4
stack backtrace:
   0: std::panicking::Location::column
   1: std::panicking::Location::column
   2: std::panicking::rust_panic_with_hook
   3: std::panicking::begin_panic_fmt
   4: std::panicking::begin_panic_fmt
   5: rust_begin_unwind
   6: core::panicking::panic_fmt
   7: <rustc_metadata::creader::ExternCrateInfo as core::fmt::Debug>::fmt
   8: rustc_metadata::locator::Context::maybe_load_library_crate
   9: rustc_metadata::creader::CrateLoader::new
  10: rustc_metadata::creader::CrateLoader::new
  11: <rustc_metadata::creader::CrateLoader<'a> as rustc::middle::cstore::CrateL
oader>::process_item
  12: rustc_resolve::build_reduced_graph::<impl rustc_resolve::ToNameBinding<'a>
 for (&'a rustc_resolve::ModuleData<'a>, rustc::ty::Visibility, syntax_pos::span
_encoding::Span, syntax_pos::hygiene::Mark)>::to_name_binding
  13: <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as s
yntax::visit::Visitor<'a>>::visit_item
  14: <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as s
yntax::visit::Visitor<'a>>::visit_ty
  15: <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as s
yntax::visit::Visitor<'a>>::visit_item
  16: <rustc_resolve::resolve_imports::SingleImports<'a> as core::default::Defau
lt>::default
  17: syntax::ext::expand::MacroExpander::expand_crate
  18: syntax::ext::expand::MacroExpander::expand_crate
  19: syntax::ext::expand::MacroExpander::expand_crate
  20: <rustc_driver::Compilation as core::fmt::Debug>::fmt
  21: <rustc_driver::Compilation as core::fmt::Debug>::fmt
  22: rustc_driver::driver::compile_input
  23: rustc_driver::run_compiler
  24: <rustc_driver::pretty::UserIdentifiedItem as core::fmt::Debug>::fmt
  25: _rust_maybe_catch_panic
  26: <rustc_driver::derive_registrar::Finder as rustc::hir::itemlikevisit::Item
LikeVisitor<'v>>::visit_trait_item
  27: std::sys::imp::thread::Thread::new
  28: BaseThreadInitThunk
  29: RtlInitializeExceptionChain

error: Could not compile `owning_ref`.

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

When I copy the project to a local path, it compiles.
The project has multiple dependencies, and it seems that the error: Could not compile owning_ref. line changes non-deterministically upon repeated runs.