Compiler panics at `Box<Any>` when building docs for zmq-sys 0.9.0

[saibatizoku]

Summary

I'm working on a crate that uses the master branch on rust-zmq, which at the moment of posting is at commit 7bfd3bacca. While running Travis CI integration hooks, I tried to publish the crates documentation to GH pages, and found an error, which I later replicated on my local machine.

On my local machine, running nightly (rustc 1.25.0-nightly), I tried this code:

cargo doc -p zmq-sys --no-deps

I expected to see this happen:

A console message indicating the documentation was built successfully.

Instead, this happened:

error: internal compiler error: librustc_metadata/decoder.rs:288: Cannot decode Span without Session.

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.25.0-nightly (f62f77403 2018-01-10) running on x86_64-unknown-linux-gnu

thread 'rustc' panicked at 'Box<Any>', librustc_errors/lib.rs:508:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.

error: Could not document `zmq-sys`.

Meta

rustc --version --verbose:

rustc 1.25.0-nightly (f62f77403 2018-01-10)
binary: rustc
commit-hash: f62f774035735a06c880c48c0b9017fcc0577e33
commit-date: 2018-01-10
host: x86_64-unknown-linux-gnu
release: 1.25.0-nightly
LLVM version: 4.0

Backtrace:

stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:68
             at libstd/sys_common/backtrace.rs:57
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:380
   3: std::panicking::default_hook
             at libstd/panicking.rs:390
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:576
   5: std::panicking::begin_panic
   6: rustc_errors::Handler::bug
   7: <std::thread::local::LocalKey<T>>::with
   8: rustc::ty::context::tls::with_opt
   9: rustc::session::opt_span_bug_fmt
  10: rustc::session::bug_fmt
  11: <rustc_metadata::decoder::DecodeContext<'a, 'tcx> as serialize::serialize::SpecializedDecoder<syntax_pos::span_encoding::Span>>::specialized_decode
  12: serialize::serialize::Decoder::read_struct
  13: serialize::serialize::Decoder::read_struct
  14: <alloc::btree::map::BTreeMap<K, V> as core::iter::traits::FromIterator<(K, V)>>::from_iter
  15: rustc_metadata::decoder::<impl rustc_metadata::cstore::CrateMetadata>::item_body_nested_bodies
  16: rustc_metadata::cstore_impl::provide_extern::item_body_nested_bodies
  17: rustc::ty::maps::<impl rustc::ty::maps::queries::item_body_nested_bodies<'tcx>>::compute_result
  18: rustc::dep_graph::graph::DepGraph::with_task_impl
  19: rustc_errors::Handler::track_diagnostics
  20: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::cycle_check
  21: rustc::ty::maps::<impl rustc::ty::maps::queries::item_body_nested_bodies<'tcx>>::force
  22: rustc::ty::maps::<impl rustc::ty::maps::queries::item_body_nested_bodies<'tcx>>::try_get
  23: rustc::ty::maps::TyCtxtAt::item_body_nested_bodies
  24: rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::item_body_nested_bodies
  25: rustdoc::clean::inline::print_inlined_const
             at librustdoc/clean/inline.rs:423
  26: rustdoc::clean::inline::try_inline
             at librustdoc/clean/inline.rs:431
             at librustdoc/clean/inline.rs:101
  27: rustdoc::clean::inline::try_inline
             at librustdoc/clean/inline.rs:397
             at librustdoc/clean/inline.rs:382
             at librustdoc/clean/inline.rs:93
  28: <rustdoc::doctree::Import as rustdoc::clean::Clean<alloc::vec::Vec<rustdoc::clean::Item>>>::clean
             at librustdoc/clean/mod.rs:3002
  29: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::spec_extend
             at librustdoc/clean/mod.rs:471
             at /checkout/src/libcore/ops/function.rs:271
             at /checkout/src/libcore/option.rs:404
             at /checkout/src/libcore/iter/mod.rs:2385
             at /checkout/src/liballoc/vec.rs:1921
             at /checkout/src/liballoc/vec.rs:1818
  30: <rustdoc::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
             at /checkout/src/liballoc/vec.rs:1782
             at librustdoc/clean/mod.rs:471
  31: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::spec_extend
             at librustdoc/clean/mod.rs:477
             at /checkout/src/libcore/ops/function.rs:271
             at /checkout/src/libcore/option.rs:404
             at /checkout/src/libcore/iter/mod.rs:1251
             at /checkout/src/liballoc/vec.rs:1844
  32: <rustdoc::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
             at /checkout/src/liballoc/vec.rs:1782
             at librustdoc/clean/mod.rs:477
  33: <rustdoc::visit_ast::RustdocVisitor<'a, 'tcx> as rustdoc::clean::Clean<rustdoc::clean::Crate>>::clean
             at librustdoc/clean/mod.rs:148
  34: rustdoc::core::run_core::{{closure}}
             at librustdoc/core.rs:218
  35: <std::thread::local::LocalKey<T>>::with
             at /checkout/src/librustc_driver/driver.rs:1101
             at /checkout/src/librustc/ty/context.rs:1573
             at /checkout/src/libstd/thread/local.rs:377
             at /checkout/src/libstd/thread/local.rs:288
  36: <std::thread::local::LocalKey<T>>::with
             at /checkout/src/librustc/ty/context.rs:1570
             at /checkout/src/librustc/ty/context.rs:1557
             at /checkout/src/libstd/thread/local.rs:377
             at /checkout/src/libstd/thread/local.rs:288
  37: rustc::ty::context::TyCtxt::create_and_enter
             at /checkout/src/librustc/ty/context.rs:1554
             at /checkout/src/librustc/ty/context.rs:1197
  38: rustc_driver::driver::phase_3_run_analysis_passes
             at /checkout/src/librustc_driver/driver.rs:1024
  39: rustdoc::core::run_core
             at librustdoc/core.rs:180

error: Could not document `zmq-sys`.

Caused by:
  process didn't exit successfully: `rustdoc --crate-name zmq_sys /home/saiba/.cargo/git/checkouts/rust-zmq-171537f0d9cec03c/7bfd3ba/zmq-sys/src/lib.rs -o /home/saiba/src/neuras/target/doc -L dependency=/home/saiba/src/neuras/target/debug/deps --extern libc=/home/saiba/src/neuras/target/debug/deps/liblibc-d0c41fb15d20b024.rlib` (exit code: 101)

[GuillaumeGomez]

The problem comes from #[path = "unix.rs"]. I'll try to see what's going wrong.

[Michael-F-Bryan]

I just encountered this as well. @saibatizoku, did you find a way to work around it?

[saibatizoku]

@Michael-F-Bryan, no, I haven't been able to get it to work as it should. For now, if I need docs, I manually select the crates that don't crash (e.g. I build docs for zmq, not for zmq-sys using the --no-deps flag)

[GuillaumeGomez]

Oups, it's been a while and I forgot about it. I'll put it back into my todo list.

[Michael-F-Bryan]

The problem comes from #[path = "unix.rs"]. I'll try to see what's going wrong.

@GuillaumeGomez, it looks like you were right. In the meantime I've made a PR to rust-zmq so it doesn't trigger this ICE (erickt/rust-zmq#214).

@saibatizoku I'm not sure whether the rust-zmq repo is being actively maintained, so if you want docs you can override which zmq-sys is used in your Cargo.toml.

[patch.crates-io]
zmq-sys = { git = "https://github.com/Michael-F-Bryan/rust-zmq", branch = "ice" }

[GuillaumeGomez]

Thanks! Me and @QuietMisdreavus took a look yesterday. The details are maybe a bit dark but they'll make sense to some people: it's simply that the session is lost when going through a #[path = "..."]. We're still trying to figure out why.

Maybe someone from the @rust-lang/compiler might know about this?

[saibatizoku]

Thank you for your help with this! Like @GuillaumeGomez says, the details of this are dark to me, but I get the main idea.

@Michael-F-Bryan thank you so much for the patch for printing docs. It should help with generating docs on Travis!

Summarizing: The what and when of this issue are known:

what => ICE
when => when building docs using #[path..] on nightly

Will this issue close when we have a why, @GuillaumeGomez ?

[GuillaumeGomez]

We have a why. Just waiting for someone to understand why this why exists (presumably @eddyb, thanks to him!).