crash when crate is not `used` but referred inside a module

[bunnie]

Code

The setup to this is a bit complicated, but I will try to describe it as compactly as possible. We have a multi-crate workspace. In this example, the crate in question is called dns. It has a dual lib/bin construction, e.g. it has interfaces callable by other crates, but also its own main. There is a module called api that defines common structures between the lib/bin halves.

The bug happened only when inside the lib half of the crate, we split the the lib into two conditionally compiled sub-modules. This is the full lib.rs that causes the problem:

pub mod api;
use api::*;

#[cfg(any(target_os = "none", target_os = "xous"))]
mod hw;
#[cfg(any(target_os = "none", target_os = "xous"))]
pub use hw::*;

#[cfg(not(any(target_os = "none", target_os = "xous")))]
mod hosted;
#[cfg(not(any(target_os = "none", target_os = "xous")))]
pub use hosted::*;

It was originally just one file, with the api file included, plus the contents of mod hw directly inside the lib.rs (so basically, the goal was to make the library interface different based upon the target machine we were going for; thus, the common api crate, but either a hw or a hosted file for the contents of lib).

The compiler crash happens inside shellchat, which is another crate in the workspace that pulls in the dns crate.

The thing that triggers the crash is that we don't do this:

use dns::Dns;

Or have any use statement. We were referring to all the dns structures by their full path name (e.g., dns::Dns::new(), dns::Dns::lookup(), etc.). We didn't use it because it's just a couple of lines where we use the DNS crate and dns is a short enough name that we never got around to use the dns crate into the name space.

only after we moved the lib into subfiles did the crash happen.

And, the fix to the crash is to simply add use dns::Dns to the top of the shellchat file where we were calling DNS.

Anyways, it's not a big deal -- the workaround is painless and probably most people in practice will use a module when they start calling functions in it, we just preferred to use fully-specified names in this one case. From the looks of the bug it looks like the compiler basically expected that use statement and was looking for a path that didn't exist because it wasn't there.

Not a show stopper -- mainly just reporting it because the error message requested the bug report. Thanks for all the hard work!

Meta

rustc --version --verbose:

rustc 1.58.1 (db9d1b20b 2022-01-20)
binary: rustc
commit-hash: db9d1b20bba1968c1ec1fc49616d4742c1725b4b
commit-date: 2022-01-20
host: x86_64-pc-windows-msvc
release: 1.58.1
LLVM version: 13.0.0

Error output

Backtrace inside the click-expand below:

Backtrace

<backtrace>
  Compiling shellchat v0.1.0 (F:\largework\rust-win\code\xous-core\services\shellchat)
thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', compiler\rustc_metadata\src\rmeta\def_path_hash_map.rs:18:85
stack backtrace:
   0:     0x7ffed11d9e1f - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h157fa6bf1896703a
   1:     0x7ffed120561a - core::fmt::write::hd933995fa5a3c525
   2:     0x7ffed11cb718 - <std::io::IoSlice as core::fmt::Debug>::fmt::hb22a6129461aed2d
   3:     0x7ffed11dd736 - std::panicking::take_hook::he9e5ebb516ae9e93
   4:     0x7ffed11dd115 - std::panicking::take_hook::he9e5ebb516ae9e93
   5:     0x7ffe6432d99e - <rustc_lint[7617183523d96aea]::BuiltinCombinedPreExpansionLintPass as rustc_lint[7617183523d96aea]::passes::EarlyLintPass>::check_impl_item
   6:     0x7ffed11de049 - std::panicking::rust_panic_with_hook::hdfb9f2b0857b79cb
   7:     0x7ffed11ddabf - rust_begin_unwind
   8:     0x7ffed11da747 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h157fa6bf1896703a
   9:     0x7ffed11dda49 - rust_begin_unwind
  10:     0x7ffed1239a40 - core::panicking::panic_fmt::h0e1c9b751cd7872a
  11:     0x7ffed123998c - core::panicking::panic::hc887acba2270eb88
  12:     0x7ffe67ef933f - <rustc_metadata[a553eabe4933b390]::creader::CStore as rustc_session[7e55dc9839d3606e]::cstore::CrateStore>::def_path_hash_to_def_id
  13:     0x7ffe68782dd7 - <rustc_middle[ff7e0ef075a5e190]::ty::context::TyCtxt>::def_path_hash_to_def_id
  14:     0x7ffe6887662e - <rustc_query_system[ea294a3d7add80ba]::dep_graph::dep_node::DepNode<rustc_middle[ff7e0ef075a5e190]::dep_graph::dep_node::DepKind> as rustc_middle[ff7e0ef075a5e190]::dep_graph::dep_node::DepNodeExt>::extract_def_id
  15:     0x7ffe67af0d53 - rustc_query_impl[45896b7db3cc92f1]::query_callbacks::adt_def
  16:     0x7ffe68767af3 - <rustc_middle[ff7e0ef075a5e190]::ty::context::TyCtxt as rustc_query_system[ea294a3d7add80ba]::dep_graph::DepContext>::try_force_from_dep_node
  17:     0x7ffe67b235ab - rustc_query_impl[45896b7db3cc92f1]::query_callbacks::diagnostic_hir_wf_check
  18:     0x7ffe67b23587 - rustc_query_impl[45896b7db3cc92f1]::query_callbacks::diagnostic_hir_wf_check
  19:     0x7ffe67b23587 - rustc_query_impl[45896b7db3cc92f1]::query_callbacks::diagnostic_hir_wf_check
  20:     0x7ffe67b23587 - rustc_query_impl[45896b7db3cc92f1]::query_callbacks::diagnostic_hir_wf_check
  21:     0x7ffe67b23587 - rustc_query_impl[45896b7db3cc92f1]::query_callbacks::diagnostic_hir_wf_check
  22:     0x7ffe67afb8bd - rustc_query_impl[45896b7db3cc92f1]::query_callbacks::diagnostic_hir_wf_check
  23:     0x7ffe67827dec - <rustc_mir_dataflow[204209cfb57e373]::framework::engine::RustcMirAttrs>::output_path
  24:     0x7ffe6797aba2 - <rustc_mir_dataflow[204209cfb57e373]::framework::engine::RustcMirAttrs>::output_path
  25:     0x7ffe64521ac1 - <rustc_interface[d7ab38303f68c91e]::passes::boxed_resolver::BoxedResolver>::to_resolver_outputs
  26:     0x7ffe64477d26 - rustc_interface[d7ab38303f68c91e]::passes::analysis
  27:     0x7ffe67a81cdb - <rustc_span[2d757f059925335b]::def_id::DefIndex as rustc_query_impl[45896b7db3cc92f1]::profiling_support::SpecIntoSelfProfilingString>::spec_to_self_profile_string
  28:     0x7ffe67b56f1e - rustc_query_impl[45896b7db3cc92f1]::query_callbacks::diagnostic_hir_wf_check
  29:     0x7ffe67a25ab1 - <rustc_query_impl[45896b7db3cc92f1]::queries::diagnostic_hir_wf_check as rustc_query_system[ea294a3d7add80ba]::query::config::QueryDescription<rustc_query_impl[45896b7db3cc92f1]::plumbing::QueryCtxt>>::describe
  30:     0x7ffe6791fbe1 - <rustc_mir_dataflow[204209cfb57e373]::framework::engine::RustcMirAttrs>::output_path
  31:     0x7ffe67a560d2 - <rustc_query_impl[45896b7db3cc92f1]::Queries as rustc_middle[ff7e0ef075a5e190]::ty::query::QueryEngine>::try_mark_green
  32:     0x7ffe6439d7ca - <rustc_driver[ac5015f618b0d469]::args::Error as core[a1a53ba5778ea5ee]::fmt::Debug>::fmt
  33:     0x7ffe643539ec - <rustc_middle[ff7e0ef075a5e190]::ty::SymbolName as core[a1a53ba5778ea5ee]::fmt::Display>::fmt
  34:     0x7ffe643451db - <chalk_engine[160540b4fe62f842]::TableIndex>::increment
  35:     0x7ffe643713f1 - <rustc_middle[ff7e0ef075a5e190]::ty::SymbolName as core[a1a53ba5778ea5ee]::fmt::Display>::fmt
  36:     0x7ffe64350a03 - rustc_driver[ac5015f618b0d469]::pretty::print_after_hir_lowering
  37:     0x7ffe643b8748 - <rustc_driver[ac5015f618b0d469]::args::Error as core[a1a53ba5778ea5ee]::fmt::Debug>::fmt
  38:     0x7ffed11ec39c - std::sys::windows::thread::Thread::new::h5e9e6e3c717bd931
  39:     0x7fff5d1f7034 - BaseThreadInitThunk
  40:     0x7fff5d722651 - RtlUserThreadStart

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/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.58.1 (db9d1b20b 2022-01-20) running on x86_64-pc-windows-msvc

note: compiler flags: -C opt-level=3 -C lto=fat -C codegen-units=1 -C debuginfo=2 -C incremental --crate-type bin

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

query stack during panic:
#0 [analysis] running analysis passes on this crate
end of query stack
error: could not compile `shellchat`

[workingjubilee]

This is hilarious.

[workingjubilee]

That def_path_hash_to_def_id makes me itch, as it often suggests an incremental compilation error, but that is just the hairs on the back of my neck talking and not really knowledge. I wonder if this still reproduces with today's Rust?

For the next Rust developer's later debugging reference, note this pair of commits:

• betrusted-io/xous-core@535a090
• betrusted-io/xous-core@0dbf166

It also includes the workaround in services/shellchat/src/cmds/net_cmds.rs, line 11 (which still lies there unto this day!), so you will have to remove it to diagnose.

[bunnie]

I just ran it against rustc 1.67.1 (d5a82bbd2 2023-02-07), with the patches removed, and it did not crash! Should we just close the issue then since it seems to have somehow gone away?

[workingjubilee]

Oh cool!

Doing some research, it seems like this was prooobably fixed along with one of these:

• thread 'rustc' panicked at 'called Option::unwrap() on a None value', compiler/rustc_metadata/src/rmeta/def_path_hash_map.rs:23:85 #100521
• ICE: Failed to extract DefId: local_def_id_to_hir_id #99233
• failed to lookup SourceFile in new context #92163
• thread 'rustc' panicked at 'called Option::unwrap() on a None value', /rustc/<snip>/compiler/rustc_hir/src/definitions.rs:452:14 #91696

So yeah, we can close it!

[bunnie]

thanks!!