Skip to content
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

Upgrading nightly introduces compiler panic at visit_opaque_types #58817

Open
xrl opened this issue Feb 28, 2019 · 9 comments

Comments

@xrl
Copy link

commented Feb 28, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

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

@xrl

This comment has been minimized.

Copy link
Author

commented Mar 1, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2019

@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

This comment has been minimized.

Copy link
Author

commented Mar 24, 2019

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

@xrl xrl closed this Mar 24, 2019

@xrl

This comment has been minimized.

Copy link
Author

commented Mar 28, 2019

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 xrl reopened this Mar 28, 2019

@xrl

This comment has been minimized.

Copy link
Author

commented Mar 28, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 11, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.