thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value'

[sfackler]

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:355:21
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::continue_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::panicking::panic
  10: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_pat
  11: syntax::visit::walk_pat
  12: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O>>::process_var_decl_multi
  13: syntax::visit::walk_expr
  14: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_item
  15: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_item
  16: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_mod
  17: <rustc_save_analysis::CallbackHandler<'b> as rustc_save_analysis::SaveHandler>::save
  18: rustc::dep_graph::graph::DepGraph::with_ignore
  19: <rls::build::rustc::RlsRustcCalls as rustc_driver::CompilerCalls<'a>>::build_controller::{{closure}}
  20: rustc::ty::context::tls::with_context
  21: rustc_driver::driver::compile_input::{{closure}}
  22: rustc::ty::context::tls::enter_context
  23: <std::thread::local::LocalKey<T>>::with
  24: rustc::ty::context::TyCtxt::create_and_enter
  25: rustc_driver::driver::compile_input
  26: rustc_driver::run_compiler_with_pool
  27: <scoped_tls::ScopedKey<T>>::set
  28: rustc_driver::run_compiler
  29: <scoped_tls::ScopedKey<T>>::set
  30: syntax::with_globals
  31: std::panicking::try::do_call
  32: __rust_maybe_catch_panic
  33: rustc_driver::run
  34: std::panicking::try::do_call
  35: __rust_maybe_catch_panic
  36: rls::build::rustc::rustc
  37: <rls::build::cargo::RlsExecutor as cargo::core::compiler::Executor>::exec
  38: cargo::core::compiler::Executor::exec_and_capture_output
  39: cargo::core::compiler::rustc::{{closure}}
  40: <F as cargo::core::compiler::job::FnBox<A, R>>::call_box
  41: <F as cargo::core::compiler::job::FnBox<A, R>>::call_box
  42: <F as cargo::core::compiler::job::FnBox<A, R>>::call_box
  43: cargo::core::compiler::job::Job::run
  44: crossbeam_utils::thread::ScopedThreadBuilder::spawn::{{closure}}
query stack during panic:
end of query stack

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.32.0 (9fda7c223 2019-01-16) running on x86_64-apple-darwin

[Xanewok]

Thanks for the report!

This seems to have happened when processing patterns in match, if let or while let, if I had to guess that'd probably be this (so I'm guessing we can't find a type definition for an enum variant and/or struct in the struct destructuring syntax?).

Do you think you could try and minimize the crashing source?

[sfackler]

so I'm guessing we can't find a type definition for an enum variant and/or struct in the struct destructuring syntax?

This seems like a pretty plausible guess. The panic popped up while I was in the middle of a refactor, so a bunch of previously existing enum and struct definitions that used to exist were gone. Seems like that part of the analysis may be over-confident about the state of the program?

Do you think you could try and minimize the crashing source?

Probably not, unfortunately :(