rustc 1.43.1 panic "inconsistent resolution for an import" specific to x86_64-pc-windows-gnu

[nguiard]

Minimal reproduction

Create a new project, add clap-v3 = "3.0.0-beta.1" in Cargo.toml. Compiles fine on linux, mac, windows with msvc toolchain, but panics on x86_64-pc-windows-gnu.

Tried with cross build --target x86_64-pc-windows-gnu on a linux server, but also cargo build --target x86_64-pc-windows-gnu on a Windows 10 VM. Both fail. Also fail if you do a --release build.

Interestingly, if you put clap = "3.0.0-beta.1" instead of clap-v3 = "3.0.0-beta.1" in Cargo.toml, everything builds fine. (Problem for me is, some dependency I use in a bigger project has itself a dependency on clap-v3 instead of clap)

Full output with backtrace

   Compiling clap-v3 v3.0.0-beta.1
thread 'rustc' panicked at 'src\librustc_resolve\imports.rs:1044: inconsistent resolution for an import', <::std::macros::panic macros>:2:4
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: <std::io::IoSlice as core::fmt::Debug>::fmt
   3: std::panicking::take_hook
   4: std::panicking::take_hook
   5: rustc_driver::report_ice
   6: std::panicking::rust_panic_with_hook
   7: <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor as rustc_ast::visit::Visitor>::visit_ty
   8: <rustc::middle::resolve_lifetime::Region as rustc_resolve::late::lifetimes::RegionExt>::shifted_out_to_binder
   9: <rustc::middle::resolve_lifetime::Region as rustc_resolve::late::lifetimes::RegionExt>::shifted_out_to_binder
  10: <rustc::middle::resolve_lifetime::Region as rustc_resolve::late::lifetimes::RegionExt>::shifted_out_to_binder
  11: <rustc::middle::resolve_lifetime::Region as rustc_resolve::late::lifetimes::RegionExt>::shifted_out_to_binder
  12: <rustc::middle::resolve_lifetime::Region as rustc_resolve::late::lifetimes::RegionExt>::shifted_out_to_binder
  13: ZN13rustc_resolve19build_reduced_graph199_$LT$impl$u20$rustc_resolve..ToNameBinding$u20$for$u20$$LP$$RF$rustc_resolve..ModuleData$C$$u20$rustc..ty..Visibility$C$$u20$rustc_span..span_encoding..Span$C$$u20$rustc_span..hygiene..ExpnId$RP$$GT$15to_name_bindi
  14: rustc_resolve::imports::ImportResolver::finalize_imports
  15: rustc_resolve::imports::ImportResolver::finalize_imports
  16: rustc_resolve::Resolver::resolve_crate
  17: rustc_interface::passes::BoxedResolver::to_resolver_outputs
  18: <rustc_interface::util::ReplaceBodyWithLoop as rustc_ast::mut_visit::MutVisitor>::visit_mac
  19: <rustc_interface::util::ReplaceBodyWithLoop as rustc_ast::mut_visit::MutVisitor>::visit_mac
  20: rustc_interface::interface::parse_cfgspecs
  21: rustc_interface::queries::Queries::expansion
  22: <rustc_ast::ast::Item as rustc_ast::attr::HasAttrs>::attrs
  23: <rustc_driver::DEFAULT_HOOK as core::ops::deref::Deref>::deref
  24: _rust_maybe_catch_panic
  25: <rustc_ast::ast::Item as rustc_ast::attr::HasAttrs>::attrs
  26: ZN244_$LT$std..error..$LT$impl$u20$core..convert..From$LT$alloc..string..String$GT$$u20$for$u20$alloc..boxed..Box$LT$dyn$u20$std..error..Error$u2b$core..marker..Sync$u2b$core..marker..Send$GT$$GT$..from..StringError$u20$as$u20$core..fmt..Display$GT$3fmt17
  27: std::sys::windows::thread::Thread::new
  28: BaseThreadInitThunk
  29: RtlUserThreadStart
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

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.43.1 (8d69840ab 2020-05-04) running on x86_64-pc-windows-msvc

note: compiler flags: -C debuginfo=2 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
error: could not compile `clap-v3`.

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

[petrochenkov]

Looks like a duplicate of #56935.
The issue is specific to cross-compilation rather than to windows-gnu.

[nguiard]

@petrochenkov Interesting. So it is considered cross-compiling when I'm on the Windows 10 VM doing cargo build --target x86_64-pc-windows-gnu? Is it because host != target like the issue you reference?

Do you think that would be an approachable issue to try and hack on for me (not much knowledge of the compiler internals)?

[petrochenkov]

That's purely due to host != target, IIRC.

Do you think that would be an approachable issue to try and hack on for me (not much knowledge of the compiler internals)?

I don't know ¯_(ツ)_/¯
The problem should be isolated in librustc_metadata/creader.rs and librustc_metadata/locator.rs, but the logic there is pretty messy.
The issue here is that we may attempt to load a crate with the same name more than once, but the second time doesn't hit the cache of "already loaded crates" and produces a new crate ID.

[petrochenkov]

@nguiard
An alternative "fix" that should be much easier to try - #56935 (comment).

[mati865]

So it is considered cross-compiling when I'm on the Windows 10 VM doing cargo build --target x86_64-pc-windows-gnu? Is it because host != target like the issue you reference?

This is the definition of cross-compilation 😄

[nguiard]

This is the definition of cross-compilation 😄

Yeah but in common terms, you're not doing cross-compilation when you're compiling on a Windows host for that very Windows host (whatever the toolchain at use, gnu or msvc etc). Host "platform" (architecture, vendor, system) is exactly the same as target. The only difference is ABI. I understand now, but not knowing much about these details when reporting the issue, I found it at first surprising that host would be different to target and that this would be considered cross-compilation.

[Elinvynia]

@petrochenkov is this safe to close as a duplicate?

[petrochenkov]

Closing as a duplicate of #56935.