Unwrap of None value in newest nightly

[sfackler]

After updating to the new nightly (2018-08-31), I'm seeing this panic in RLS when doing the initial analysis for a large internal project:

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:345:21
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::SaveContext::get_field_ref_data
  11: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O>>::process_struct_lit
  12: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_expr
  13: syntax::visit::walk_expr
  14: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_local
  15: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_expr
  16: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O>>::process_method
  17: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_item
  18: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_mod
  19: <rustc_save_analysis::CallbackHandler<'b> as rustc_save_analysis::SaveHandler>::save
  20: rustc::ty::context::tls::with_context
  21: <rls::build::rustc::RlsRustcCalls as rustc_driver::CompilerCalls<'a>>::build_controller::{{closure}}
  22: rustc::ty::context::tls::with_context
  23: rustc_driver::driver::compile_input::{{closure}}
  24: rustc::ty::context::tls::enter_context
  25: <std::thread::local::LocalKey<T>>::with
  26: rustc::ty::context::TyCtxt::create_and_enter
  27: rustc_driver::driver::compile_input
  28: rustc_driver::run_compiler_with_pool
  29: <scoped_tls::ScopedKey<T>>::set
  30: rustc_driver::run_compiler
  31: <scoped_tls::ScopedKey<T>>::set
  32: syntax::with_globals
  33: std::panicking::try::do_call
  34: __rust_maybe_catch_panic
  35: rustc_driver::run
  36: std::panicking::try::do_call
  37: __rust_maybe_catch_panic
  38: rls::build::rustc::rustc
  39: <rls::build::cargo::RlsExecutor as cargo::core::compiler::Executor>::exec
  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: <F as crossbeam_utils::thread::FnBox<T>>::call_box
  45: __rust_maybe_catch_panic
  46: <F as alloc::boxed::FnBox<A>>::call_box
  47: std::sys_common::thread::start_thread
  48: std::sys::unix::thread::Thread::new::thread_start
  49: _pthread_body
  50: _pthread_start
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.30.0-nightly (f8d34596f 2018-08-30) running on x86_64-apple-darwin

[dralley]

@nrc, if this issue is fixed by that commit, shouldn't it have been closed?