New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rustdoc ICE with argument position impl Trait #46976

Closed
CAD97 opened this Issue Dec 24, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@CAD97
Copy link
Contributor

CAD97 commented Dec 24, 2017

#![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

This comment has been minimized.

Copy link
Contributor Author

CAD97 commented Dec 24, 2017

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

This comment has been minimized.

Copy link
Contributor Author

CAD97 commented Dec 24, 2017

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 added a commit to CAD97/rust that referenced this issue Dec 24, 2017

@CAD97

This comment has been minimized.

Copy link
Contributor Author

CAD97 commented Dec 24, 2017

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

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.

CAD97 added a commit to nafi-lang/rust-nafi that referenced this issue Dec 24, 2017

Temprorary rust-lang/rust#46976 workaround
nnom is going away, which is where the error is, so this should be temporary so bors can merge PRs

CAD97 added a commit to nafi-lang/rust-nafi that referenced this issue Dec 24, 2017

bors bot added a commit to nafi-lang/rust-nafi that referenced this issue Dec 24, 2017

Merge #13
13: Revert "Temprorary rust-lang/rust#46976 workaround" r=CAD97 a=CAD97

This reverts commit 625420f.
@estebank

This comment has been minimized.

Copy link
Contributor

estebank commented Dec 26, 2017

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

@CAD97

This comment has been minimized.

Copy link
Contributor Author

CAD97 commented Dec 27, 2017

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

This comment has been minimized.

Copy link
Contributor

estebank commented Dec 27, 2017

@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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment