Rustdoc ICE with argument position impl Trait

[CAD97]

#![feature(universal_impl_trait)]

pub fn ice(f: impl Fn()) {}

$ rustdoc src/lib.rs
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.24.0-nightly (250b49205 2017-12-21) running on x86_64-pc-windows-msvc

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

thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 18446744073709551615', C:\projects\rust\src\liballoc\vec.rs:1549:10
stack backtrace:
   0: <std::fs::DirBuilder as core::fmt::Debug>::fmt
   1: <std::sync::condvar::Condvar as core::fmt::Debug>::fmt
   2: std::panicking::Location::column
   3: std::panicking::Location::column
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic_fmt
   6: std::panicking::begin_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::panicking::panic_bounds_check
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: _rust_maybe_catch_panic
  21: <unknown>
  22: <std::sync::condvar::Condvar as core::fmt::Debug>::fmt
  23: std::sys::windows::thread::Thread::new
  24: BaseThreadInitThunk

According to my Travis logs, this is a regression between (last good)

$ rustc --version
rustc 1.24.0-nightly (7eb64b86c 2017-12-20)
$ rustup --version
rustup 1.8.0 (cb2d14862 2017-12-17)
$ cargo --version
cargo 0.25.0-nightly (930f9d949 2017-12-05)

and (first bad)

$ rustc --version
rustc 1.24.0-nightly (5165ee9e2 2017-12-22)
$ rustup --version
rustup 1.8.0 (cb2d14862 2017-12-17)
$ cargo --version
cargo 0.25.0-nightly (930f9d949 2017-12-05)

though complicated by the fact that my build broke on 46959 in the same interval. Actually, we're in luck, I had 1.24.0-nightly (250b49205 2017-12-21) locally which also errors. So the interval is 7eb64b8...250b492 (probably).

e502194 from #46754 pops out as relevant, @cramertj?

[CAD97]

FWIW, I just got rustc (almost -- run-make fails) compiling on my setup, and would be interested in trying my hand digging further into this, but I'm not really sure how to set up a "compile-pass" (or any) rustdoc test.

UPDATE: Got a failing test working

[CAD97]

UPDATE: I was wrong to suspect e502194, I think, sorry cramertj

INFO:rustdoc: finished with rustc
INFO:rustdoc: loading plugins...
INFO:rustdoc: Executing passes/plugins
INFO:rustdoc: going to format
INFO:rustdoc::html::render: emitting source files
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.24.0-dev running on x86_64-pc-windows-msvc

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

thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 18446744073709551615', D:\rust-lang\rust\src\liballoc\vec.rs:1551:10
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys_common::backtrace::_print
   1: std::panicking::Location::column
   2: std::panicking::Location::column
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::panicking::panic_bounds_check
   9: rustdoc::html::render::get_index_type_name
  10: rustdoc::html::render::get_index_type
  11: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
  12: <rustdoc::html::render::Cache as rustdoc::fold::DocFolder>::fold_item
  13: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
  14: <rustc::ty::VariantDef as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
  15: <rustdoc::html::render::Cache as rustdoc::fold::DocFolder>::fold_item
  16: rustdoc::html::render::run


------------------------------------------

thread '[rustdoc] rustdoc\issue-46976.rs' panicked at 'explicit panic', src\tools\compiletest\src\runtest.rs:2776:8

[CAD97]

Trace says it's rustdoc::html::render::get_index_type_name

rust/src/librustdoc/html/render.rs

Lines 4129 to 4141 in 8d4da4f

	fn get_index_type_name(clean_type: &clean::Type, accept_generic: bool) -> Option<String> {
	match *clean_type {
	clean::ResolvedPath { ref path, .. } => {
	let segments = &path.segments;
	Some(segments[segments.len() - 1].name.clone())
	}
	clean::Generic(ref s) if accept_generic => Some(s.clone()),
	clean::Primitive(ref p) => Some(format!("{:?}", p)),
	clean::BorrowedRef { ref type_, .. } => get_index_type_name(type_, accept_generic),
	// FIXME: add all from clean::Type.
	_ => None
	}
	}

Sure enough, this is underflow:

-4133       Some(segments[segments.len() - 1].name.clone())
+4133       let path_segment = segments.into_iter().last().unwrap_or_else(|| panic!( 
+4134           "get_index_type_name(clean_type: {:?}, accept_generic: {:?}) had length zero path", 
+4135           clean_type, accept_generic 
+4136       ));
+4137       Some(path_segment.name.clone())

thread 'rustc' panicked at 'get_index_type_name(clean_type: ResolvedPath { path: Path { global: false, def: TyParam(DefId(0/1:10)), segments: [] }, typarams: None, did: DefId(0/1:1
0), is_generic: true }, accept_generic: true) had length zero path', src\librustdoc\html\render.rs:4133:77
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys_common::backtrace::_print
   1: std::panicking::Location::column
   2: std::panicking::Location::column
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: std::panicking::begin_panic_fmt
   6: rustdoc::html::render::get_index_type_name
             at .\src\librustdoc\html\render.rs:4145
   7: rustdoc::html::render::get_index_type
             at .\src\librustdoc\html\render.rs:4123
   8: alloc::vec::{{impl}}::from_iter<rustdoc::html::render::Type,core::iter::Map<core::slice::Iter<rustdoc::clean::Argument>, closure>>
             at .\src\liballoc\vec.rs:1825
   9: rustdoc::html::render::{{impl}}::fold_item
             at .\src\librustdoc\html\render.rs:1269
  10: alloc::vec::{{impl}}::from_iter<rustdoc::clean::Item,core::iter::FilterMap<alloc::vec::IntoIter<rustdoc::clean::Item>, closure>>
             at .\src\liballoc\vec.rs:1795
  11: rustdoc::fold::DocFolder::fold_inner_recur<rustdoc::html::render::Cache>
             at .\src\librustdoc\fold.rs:42
  12: rustdoc::html::render::{{impl}}::fold_item
             at .\src\librustdoc\html\render.rs:1367
  13: rustdoc::html::render::run
             at .\src\librustdoc\html\render.rs:636


------------------------------------------

thread '[rustdoc] rustdoc\issue-46976.rs' panicked at 'explicit panic', src\tools\compiletest\src\runtest.rs:2776:8

Work done so far: CAD97/rust@75c2824

I'm not really sure where to go from here. Attempted to revert ab7abfc, got a broken mess.

I'm thinking it was #46754 again, but lack the tools to bisect. @cramertj, have any ideas? The problem is that an argument position impl Trait is generating a zero-segment Path for rustdoc.

[estebank]

@CAD97 the actual issue is possibly in librustdoc/clean/mod.rs not handling impl Trait correctly. Thank you for digging into this!

[CAD97]

I noticed that the PR in question did remove the match for TyImplTraitUniversal, because TyImplTraitUniversal was removed.

Here's the line where the empty path.segments is generated: e502194#diff-64b696b0ef6ad44140e973801ed82b25R1000

I think the problem is thus cleaning getting clean::Type::ResolvedPath for argument position impl Trait, rather than clean::ImplTrait as before. I'm having trouble tracking the path that the definition takes though.

[estebank]

@CAD97 something that I find useful in cases like that is to use the debugger:

% rust-lldb ./stage1/bin/rustc file.rs
(lldb) ---8< ---
(lldb) breakpoint set --func-regex ".*<METHOD_NAME>.*"
(lldb) run
(lldb) bt
 --- 8< ---

That will print out the backtrace of the chain of callers of that method (you can use n to continue until the breakpoint hits again until you get to the actual call you care about).