cargo doc fails with panic in rustc.

[zakarumych]

I try to document crate (with cargo doc) and rustc panics.
Although cargo build works well
It seems that those lines causing the panic:

In lib.rs:

extern crate gfx_mesh;
pub use gfx_mesh::{Mesh, MeshBuilder};

In Cargo.toml:

gfx-mesh = { git = "https://github.com/omni-viral/gfx-mesh", rev = "3ee315b8" }

Meta

rustc --version --verbose:

rustc 1.25.0 (84203cac6 2018-03-25)
binary: rustc
commit-hash: 84203cac67e65ca8640b8392348411098c856985
commit-date: 2018-03-25
host: x86_64-apple-darwin
release: 1.25.0
LLVM version: 6.0

RUST_BACKTRACE=full cargo doc :

 Documenting test1 v0.1.0 (file:///Users/zakarum/pet/test1)
error: internal compiler error: librustc_metadata/decoder.rs:289: Cannot decode Span without Session.

thread 'rustc' panicked at 'Box<Any>', librustc_errors/lib.rs:535:9
stack backtrace:
   0:        0x106897c33 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h0d82ff21dbaafa37
   1:        0x10688f0a2 - std::sys_common::backtrace::_print::h8d6c54c009c3f040
   2:        0x1068949ad - std::panicking::default_hook::{{closure}}::h9fa6009de31be346
   3:        0x106894645 - std::panicking::default_hook::h6cdceadee11175c8
   4:        0x106894e56 - std::panicking::rust_panic_with_hook::hfb431ab23831437f
   5:        0x1065d8a0b - std::panicking::begin_panic::h6fc6d7cefc0d4156
   6:        0x1065fb2f8 - rustc_errors::Handler::bug::hb776eb7b63578a78
   7:        0x1051f5de8 - rustc::session::opt_span_bug_fmt::{{closure}}::hb4e6a7d91782852f
   8:        0x1052b3310 - rustc::ty::context::tls::with_opt::{{closure}}::h67ee5dec967f3ca6
   9:        0x104ed7ae8 - <std::thread::local::LocalKey<T>>::try_with::h83302cce55a9bec1
  10:        0x104ed79a4 - <std::thread::local::LocalKey<T>>::with::hef48b88bcdafcec3
  11:        0x1052b30d4 - rustc::ty::context::tls::with::heca45bdf3c9a1d1a
  12:        0x1052b32cf - rustc::ty::context::tls::with_opt::h4cdf0ab166451878
  13:        0x1051f5a74 - rustc::session::opt_span_bug_fmt::h36de7c1db41875d5
  14:        0x1051f5941 - rustc::session::bug_fmt::h41decc888dfbf2e6
  15:        0x10440d06c - <rustc_metadata::decoder::DecodeContext<'a, 'tcx> as serialize::serialize::SpecializedDecoder<syntax_pos::span_encoding::Span>>::specialized_decode::h4c296349ad36a672
  16:        0x10438799b - <rustc::hir::Expr as serialize::serialize::Decodable>::decode::{{closure}}::hbdd7bf8c83a47d59
  17:        0x104387152 - <rustc::hir::Body as serialize::serialize::Decodable>::decode::h5b6241b50756a11c
  18:        0x104413268 - rustc_metadata::decoder::<impl rustc_metadata::cstore::CrateMetadata>::item_body_nested_bodies::hfbae0d4a4f24ecc8
  19:        0x10443ceff - rustc_metadata::cstore_impl::provide_extern::item_body_nested_bodies::he7c82522188ca22d
  20:        0x105082b6b - rustc::dep_graph::graph::DepGraph::with_task_impl::h7fe2b0833d41da61
  21:        0x1053c6be5 - rustc::ty::maps::<impl rustc::ty::maps::queries::item_body_nested_bodies<'tcx>>::force::h1f37875260b763f4
  22:        0x1053c791c - rustc::ty::maps::<impl rustc::ty::maps::queries::item_body_nested_bodies<'tcx>>::try_get::hd52813c28b9c0cfd
  23:        0x1054940b1 - rustc::ty::maps::TyCtxtAt::item_body_nested_bodies::h7db16ad29a2b4eaa
  24:        0x10548f878 - rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::item_body_nested_bodies::hf3045fc98bededdb
  25:        0x103602a18 - rustdoc::clean::inline::print_inlined_const::h8e412b9e23a94ec9
  26:        0x10361cea8 - <rustc::ty::AssociatedItem as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean::hee07e803dcc25ca1
  27:        0x103601196 - rustdoc::clean::inline::build_impl::hd3f2c399005c6cea
  28:        0x1036006bf - rustdoc::clean::inline::build_impls::hf99fd01c6864bd24
  29:        0x1035fd34c - rustdoc::clean::inline::try_inline::h19432d1a13e069a3
  30:        0x103629767 - <rustdoc::doctree::Import as rustdoc::clean::Clean<alloc::vec::Vec<rustdoc::clean::Item>>>::clean::h12f42038fa8b0afa
  31:        0x103609c82 - <rustdoc::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean::hcd3b4c90d503d265
  32:        0x1036070fd - <rustdoc::visit_ast::RustdocVisitor<'a, 'tcx, 'rcx> as rustdoc::clean::Clean<rustdoc::clean::Crate>>::clean::hfca985fa4a441e9f
  33:        0x1036311b2 - rustdoc::core::run_core::{{closure}}::ha95fee8bdba89da6
  34:        0x10358d803 - rustc::ty::context::TyCtxt::create_and_enter::hdb7b2dcd4696caa0
  35:        0x10362fc49 - rustdoc::core::run_core::hc3958f60514f70ba
  36:        0x103521bf6 - std::sys_common::backtrace::__rust_begin_short_backtrace::hf3094eb672591957
  37:        0x10352592d - std::panicking::try::do_call::h524e0ae617f35cca
  38:        0x1068afa4e - __rust_maybe_catch_panic
  39:        0x1035764e5 - <F as alloc::boxed::FnBox<A>>::call_box::h9ea7b93789e882bb
  40:        0x1068a465b - std::sys::unix::thread::Thread::new::thread_start::h2f926488e05dc513
  41:     0x7fffe2c0193a - _pthread_body
  42:     0x7fffe2c01886 - _pthread_start

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 (84203cac6 2018-03-25) running on x86_64-apple-darwin

error: Could not document `test1`.

Caused by:
  process didn't exit successfully: `rustdoc --crate-name test1 src/lib.rs -o /Users/zakarum/pet/test1/target/doc -L dependency=/Users/zakarum/pet/test1/target/debug/deps --extern gfx_hal=/Users/zakarum/pet/test1/target/debug/deps/libgfx_hal-a2dbed14be3e1c1d.rmeta --extern gfx_mesh=/Users/zakarum/pet/test1/target/debug/deps/libgfx_mesh-e2a3fc73bd9fdd51.rmeta` (exit code: 101)

[pietroalbini]

Thanks for reporting this! Can you post the full output?

[zakarumych]

@pietroalbini full output in terminal? Sure. I'll edit in the post

[QuietMisdreavus]

Good news: this is fixed on nightly.

Bad news: it's busted on beta and stable.

From what i can tell of the stack trace, it has something to do with cleaning an item with an associated const? The only associated consts in this crate aren't even exported by the demo - they're secondhand from the types that are. The only suspect associated consts i can tell are ones like these:

impl<T> AsVertexFormat for T
where
    T: Attribute,
{
    // i'd say the implied 'static on that slice is suspect, but it's actually explicit in the const declaration >_>
    const VERTEX_FORMAT: VertexFormat<'static> = VertexFormat {
        attributes: Cow::Borrowed(&[
            Element {
                format: T::SELF,
                offset: 0,
            },
        ]),
        stride: T::SIZE,
    };
}

impl AsFormat for Position {
    // AsFormat and its impl on `[f32; 3]` are themselves pulled from a separate crate, `gfx-hal`
    const SELF: Format = <[f32; 3] as AsFormat>::SELF;
}

I'm not totally sure what the real problem is that it's having. I need to dig farther.

[QuietMisdreavus]

Update: Rustdoc is pulling in the offending trait implementations because rustdoc pulls in every trait implementation when it imports an item from another crate. The code i poked at within rustdoc itself seemed to not change very much between beta and nightly, so i suspect the failure is in the const rendering code, likely in rustc_metadata. More digging is required.

[pietroalbini]

Bisected this, fixed in PR #49386.

For the record, documenting on the latest nightly outputs:

warning: [Surface] cannot be resolved, ignoring it...
warning: [Swapchain] cannot be resolved, ignoring it...
warning: [cfg] cannot be resolved, ignoring it...
warning: [T] cannot be resolved, ignoring it...
warning: [u8] cannot be resolved, ignoring it...
warning: [Garbage] cannot be resolved, ignoring it...
warning: [Experimental] cannot be resolved, ignoring it...
warning: [flat_map] cannot be resolved, ignoring it...
warning: [Owned] cannot be resolved, ignoring it...
warning: [Pin] cannot be resolved, ignoring it...

[QuietMisdreavus]

@pietroalbini Thanks! Those warnings are intra-link resolution problems. I opened #50082 to ensure we don't get any in std.

[QuietMisdreavus]

Hmm, if that PR fixed it, then this issue would be a duplicate of #47391, which that PR fixed. Should we backport that PR so we can at least get it in beta?

[pietroalbini]

Yeah, this is a duplicate, but I don't know the policy about backporting non-regression bugfixes.

[pietroalbini]

That PR has been backported to beta. Closing this.