Upgrading nightly introduces compiler panic at visit_opaque_types

[xrl]

I did a rustup update and the new nightly started failing to compile.

I tried this code:

I don't have a good way of minimal reproduction on my medium-size codebase. But I did figure out another rustup nightly that would stop seeing the error.

I expected to see this happen: rustup default nightly; rustup update; cargo build should have kept working

Instead, this happened:

/Users/xavierlange/.cargo/bin/cargo run --color=always -- postgres://postgres@localhost/sci_rx_production http://localhost:5984 --table=request_tracker
   Compiling dracula v0.1.0 (/Users/xavierlange/code/rust/dracula)
thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', src/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_typeck::check::writeback::WritebackCx::visit_opaque_types
  11: rustc_typeck::check::writeback::<impl rustc_typeck::check::FnCtxt<'a, 'gcx, 'tcx>>::resolve_type_vars_in_body
  12: rustc::ty::context::GlobalCtxt::enter_local
  13: rustc_typeck::check::typeck_tables_of
  14: rustc::ty::query::__query_compute::typeck_tables_of
  15: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_tables_of<'tcx>>::compute
  16: rustc::dep_graph::graph::DepGraph::with_task_impl
  17: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  18: rustc_typeck::collect::type_of
  19: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::type_of<'tcx>>::compute
  20: rustc::dep_graph::graph::DepGraph::with_task_impl
  21: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  22: rustc::ty::util::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::try_expand_impl_trait_type::OpaqueTypeExpander::expand_opaque_ty
  23: rustc::ty::util::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::try_expand_impl_trait_type
  24: rustc_typeck::check::check_item_type
  25: rustc::hir::map::Map::visit_item_likes_in_module
  26: rustc_typeck::check::check_mod_item_types
  27: rustc::ty::query::__query_compute::check_mod_item_types
  28: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::check_mod_item_types<'tcx>>::compute
  29: rustc::dep_graph::graph::DepGraph::with_task_impl
  30: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  31: rustc::session::Session::track_errors
  32: rustc::util::common::time
  33: rustc_typeck::check_crate
  34: <std::thread::local::LocalKey<T>>::with
  35: rustc::ty::context::TyCtxt::create_and_enter
  36: rustc_driver::driver::compile_input
  37: rustc_driver::run_compiler_with_pool
  38: <scoped_tls::ScopedKey<T>>::set
  39: rustc_driver::run_compiler
  40: rustc_driver::monitor::{{closure}}
  41: __rust_maybe_catch_panic
  42: <F as alloc::boxed::FnBox<A>>::call_box
  43: std::sys::unix::thread::Thread::new::thread_start
  44: _pthread_body
  45: _pthread_start
query stack during panic:
#0 [typeck_tables_of] processing `tasks::request_tracker::request_tracker`
#1 [type_of] processing `tasks::request_tracker::request_tracker::{{impl-Trait}}`
#2 [check_mod_item_types] checking item types in module `tasks::request_tracker`
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.34.0-nightly (7e001e5c6 2019-02-27) running on x86_64-apple-darwin

note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

error: Could not compile `dracula`.

To learn more, run the command again with --verbose.

Process finished with exit code 101

maybe my cargo file will help? nothing fancy going on there:

[package]
name = "dracula"
version = "0.1.0"
authors = ["Xavier Lange <xrlange@gmail.com>"]
edition = "2018"

[dependencies]
parquet = { git = "https://github.com/tureus/parquet-rs.git", branch = "parquet_derive-refactor_field_info" }
parquet_derive = { git = "https://github.com/tureus/parquet-rs.git", branch = "parquet_derive-refactor_field_info" }
reqwest = "0.9"
serde = { version = "1.0", features = [ ] }
serde_derive = "1.0"
serde_json = "1.0"
docopt = "1.0"
diesel = { version = "1.0.0", features = ["postgres", "32-column-tables", "numeric", "chrono"] }
bigdecimal = "0.0.14" # gotta match the diesel version, try `cargo tree`
chrono = { version = "0.4", features = ["serde"] }
uuid = "0.7"
hashbrown = { version = "0.1", features = ["serde"] }
lazy_static = "1"
pretty-bytes = "0.2"
rusoto_core = "0.36.0"
rusoto_s3 = "0.36.0"
futures = "0.1"
url = "1.7"
# Needed for Postgres.
openssl = "*"
openssl-probe = "0.1.2"

[profile.release]
#lto = true
#debug = false
#codegen-units = 1
#panic = "abort"

[[bin]]
name = "dracula"

I can fix this by downgrading: rustup default nightly-2019-02-19 and then cargo build works again. The error starts happening on rustup default nightly-2019-02-21.

Meta

rustc --version --verbose:

$ rustc --version --verbose
rustc 1.34.0-nightly (f66e4697a 2019-02-20)
binary: rustc
commit-hash: f66e4697ae286985ddefc53c3a047614568458bb
commit-date: 2019-02-20
host: x86_64-apple-darwin
release: 1.34.0-nightly
LLVM version: 8.0

[oli-obk]

Is the source of your crate available somewhere? Do you use any unstable features? Might be existential type related

[xrl]

@oli-obk my crate is not public (it has a lot of private code) but it does have these flags on lib.rs:

#![feature(custom_attribute)]
#![feature(impl_trait_in_bindings)]
#![recursion_limit = "512"]
#![allow(proc_macro_derive_resolution_fallback)]

I could give you a copy of the code through private means if that helps.

[jethrogb]

@xrl It might be hard to diagnose this without the actual source input. If you're having trouble reducing the input, you might try an automated tool such as C-reduce.

[oli-obk]

cc @alexreg, this seems to be a crash related to impl trait in bindings.

@xrl it's most likely due to a use of impl trait in let bindings. This should help with minimizing the code, since you can scrap any functions that don't have impl Trait

[alexreg]

@xrl, impl Trait in bindings is badly broken right now, sorry. I’m going to be reworking it over the coming weeks. I suggest you don’t use it for now.

[xrl]

I just pulled down the latest nightly and rebuilt, no ICE on compile. I think this is good to close!

[xrl]

I made a mistake! I thought just running "rustup update" was enough but I guess rustup was pinned to the "stable" nightly nightly-2019-02-19. I just ran rustup default nightly; rustup update and now the app is breaking with the same errors. Sorry for the confusion, I'm back to where I was before closing!

[xrl]

The error with updated nightly:

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:345: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_typeck::check::writeback::WritebackCx::visit_opaque_types
  11: rustc_typeck::check::writeback::<impl rustc_typeck::check::FnCtxt>::resolve_type_vars_in_body
  12: rustc::ty::context::GlobalCtxt::enter_local
  13: rustc_typeck::check::typeck_tables_of
  14: rustc::ty::query::__query_compute::typeck_tables_of
  15: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::typeck_tables_of>::compute
  16: rustc::dep_graph::graph::DepGraph::with_task_impl
  17: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  18: rustc_typeck::collect::type_of
  19: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::type_of>::compute
  20: rustc::dep_graph::graph::DepGraph::with_task_impl
  21: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  22: rustc::ty::util::<impl rustc::ty::context::TyCtxt>::try_expand_impl_trait_type::OpaqueTypeExpander::expand_opaque_ty
  23: rustc::ty::util::<impl rustc::ty::context::TyCtxt>::try_expand_impl_trait_type
  24: rustc_typeck::check::check_item_type
  25: rustc::hir::map::Map::visit_item_likes_in_module
  26: rustc_typeck::check::check_mod_item_types
  27: rustc::ty::query::__query_compute::check_mod_item_types
  28: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::check_mod_item_types>::compute
  29: rustc::dep_graph::graph::DepGraph::with_task_impl
  30: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  31: rustc::session::Session::track_errors
  32: rustc_typeck::check_crate
  33: rustc_interface::passes::analysis
  34: rustc::ty::query::__query_compute::analysis
  35: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::analysis>::compute
  36: rustc::dep_graph::graph::DepGraph::with_task_impl
  37: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  38: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  39: rustc_interface::passes::create_global_ctxt::{{closure}}
  40: rustc_interface::passes::BoxedGlobalCtxt::enter
  41: rustc_interface::interface::run_compiler_in_existing_thread_pool
  42: std::thread::local::LocalKey<T>::with
  43: scoped_tls::ScopedKey<T>::set
  44: syntax::with_globals
query stack during panic:
#0 [typeck_tables_of] processing `tasks::request_tracker::request_tracker`
#1 [type_of] processing `tasks::request_tracker::request_tracker::{{opaque}}#0`
#2 [check_mod_item_types] checking item types in module `tasks::request_tracker`
#3 [analysis] running analysis passes on this crate
end of query stack

[xrl]

@alexreg I found the offending bit of code by process of elimination:

    let pages : impl Iterator<Item=(&QuotedWare, Option<&QuoteGroup>, Option<&[&QuotedWare]>)> = quoted_wares_view_response.docs().map(|qw| {
      let (qg,related_qws) = if let Some(ref qg_id) = qw.quote_group_id {
        let o_qg = quote_groups_index.get(qg_id).map(|x| *x);
        let o_qws = quote_group_quoted_wares.get(qg_id).map(|x| &x[..]);
        (o_qg,o_qws)
      } else {
        (None,None)
      };
      counter += 1;
      (qw,qg,related_qws)
    });

replacing this code with let pages = unimplemented!() gets the compiler happy again.