RLS panics at Box<Any>

[matthunz]

RLS panics when I include romio or similar crates involing futures.

use romio::TcpStream;

RLS Backtrace:

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:636:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

note: the compiler unexpectedly panicked. this is a bug.

[estebank]

Could you set the RUST_BACKTRACE=1 environment variable so we can get the full backtrace?

[matthunz]

Sure thing, here's what I got:

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:636:9
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
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   6: std::panicking::begin_panic
   7: rustc_errors::Handler::bug
   8: rustc::util::bug::opt_span_bug_fmt::{{closure}}
   9: rustc::ty::context::tls::with_opt::{{closure}}
  10: rustc::ty::context::tls::with_context_opt
  11: rustc::ty::context::tls::with_opt
  12: rustc::util::bug::opt_span_bug_fmt
  13: rustc::util::bug::bug_fmt
  14: rustc::hir::map::Map::get::{{closure}}
  15: rustc::hir::map::Map::get
  16: rustc_save_analysis::SaveContext::get_path_def
  17: <rustc_save_analysis::dump_visitor::DumpVisitor<O> as syntax::visit::Visitor>::visit_ty
  18: rustc_save_analysis::dump_visitor::DumpVisitor<O>::process_method
  19: <rustc_save_analysis::dump_visitor::DumpVisitor<O> as syntax::visit::Visitor>::visit_item
  20: <rustc_save_analysis::dump_visitor::DumpVisitor<O> as syntax::visit::Visitor>::visit_mod
  21: <rustc_save_analysis::DumpHandler as rustc_save_analysis::SaveHandler>::save
  22: rustc::dep_graph::graph::DepGraph::with_ignore
  23: rustc_driver::run_compiler::{{closure}}::{{closure}}::{{closure}}
  24: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  25: rustc_interface::passes::create_global_ctxt::{{closure}}
  26: rustc_interface::passes::BoxedGlobalCtxt::enter
  27: rustc_interface::interface::run_compiler_in_existing_thread_pool
  28: std::thread::local::LocalKey<T>::with
  29: scoped_tls::ScopedKey<T>::set
  30: syntax::with_globals
query stack during panic:
end of query stack

[dpetrick]

I believe that I'm facing a similar issue. I noticed that since the last rust toolchain upgrade (to 1.34.1), my Cargo workspace setup stopped working (with VSCode plugin). I acknowledge that workspaces are still experimental, but worked fine for me thus far. The update and the error might just coincide with a crate that was added to the project similar to the OPs issue. I will provide everything I could find below.

If the issue is unrelated, I'm happy to file a bug separately.

RLS log:

{"message":"src/librustc/ty/context.rs:541: node_type: no type for node `expr <Self>::STARTED (id=32431)`","code":null,"level":"error: internal compiler error","spans":[],"children":[],"rendered":"error: internal compiler error: src/librustc/ty/context.rs:541: node_type: no type for node `expr <Self>::STARTED (id=32431)`\n\n"}
thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:620:9
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::begin_panic
   7: rustc_errors::Handler::bug
   8: rustc::util::bug::opt_span_bug_fmt::{{closure}}
   9: rustc::ty::context::tls::with_opt::{{closure}}
  10: rustc::ty::context::tls::with_context_opt
  11: rustc::ty::context::tls::with_opt
  12: rustc::util::bug::opt_span_bug_fmt
  13: rustc::util::bug::bug_fmt
  14: rustc::ty::context::TypeckTables::node_type::{{closure}}
  15: rustc::ty::context::TypeckTables::expr_ty_adjusted
  16: rustc_save_analysis::SaveContext::get_expr_data
  17: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_expr
  18: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O>>::process_assoc_const
  19: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_item
  20: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O>>::process_method
  21: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_item
  22: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_item
  23: <rustc_save_analysis::dump_visitor::DumpVisitor<'l, 'tcx, 'll, O> as syntax::visit::Visitor<'l>>::visit_mod
  24: <rustc_save_analysis::DumpHandler<'a> as rustc_save_analysis::SaveHandler>::save
  25: rustc::dep_graph::graph::DepGraph::with_ignore
  26: rustc_driver::enable_save_analysis::{{closure}}::{{closure}}
  27: rustc_driver::enable_save_analysis::{{closure}}
  28: rustc::dep_graph::graph::DepGraph::with_ignore
  29: rustc_driver::driver::compile_input::{{closure}}
  30: <std::thread::local::LocalKey<T>>::with
  31: rustc::ty::context::TyCtxt::create_and_enter
  32: rustc_driver::driver::compile_input
  33: rustc_driver::run_compiler_with_pool
  34: <scoped_tls::ScopedKey<T>>::set
  35: rustc_driver::run_compiler
  36: <scoped_tls::ScopedKey<T>>::set
query stack during panic:
end of query stack

rustc --version --verbose:

rustc 1.34.1 (fc50f328b 2019-04-24)
binary: rustc
commit-hash: fc50f328b0353b285421b8ff5d4100966387a997
commit-date: 2019-04-24
host: x86_64-apple-darwin
release: 1.34.1
LLVM version: 8.0

[Xanewok]

@dpetrick I believe this error should be fixed with #60649 (should be available in the next nightly build)