ICE in typeck on existential return type in trait

[athre0z]

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=6988f4162312bdf3adc80228efabb896

#![feature(existential_type)]

trait UnwrapItemsExt {
    type II;
    fn unwrap_items(self) -> Self::II;
}

impl<I, T, E> UnwrapItemsExt for I 
where
    I: Iterator<Item = Result<T, E>>,
    E: std::fmt::Debug,
{
    existential type II: Iterator<Item = T>;
    
    fn unwrap_items(self) -> Self::II {
        self.map(|x| x.unwrap())
    }
}

   Compiling playground v0.0.1 (/playground)
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
             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:200
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:215
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:482
   6: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:385
   7: rust_begin_unwind
             at src/libstd/panicking.rs:312
   8: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   9: core::panicking::panic
             at src/libcore/panicking.rs:49
  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::find_existential_constraints::ConstraintLocator::check
  19: rustc::hir::intravisit::Visitor::visit_nested_impl_item
  20: rustc::hir::intravisit::walk_item
  21: rustc_typeck::collect::find_existential_constraints
  22: rustc_typeck::collect::type_of
  23: rustc::ty::query::__query_compute::type_of
  24: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::type_of<'tcx>>::compute
  25: rustc::dep_graph::graph::DepGraph::with_task_impl
  26: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  27: <rustc_typeck::collect::CollectItemTypesVisitor<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_impl_item
  28: rustc::hir::map::Map::visit_item_likes_in_module
  29: rustc_typeck::collect::collect_mod_item_types
  30: rustc::ty::query::__query_compute::collect_mod_item_types
  31: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::collect_mod_item_types<'tcx>>::compute
  32: rustc::dep_graph::graph::DepGraph::with_task_impl
  33: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  34: rustc_typeck::collect::collect_item_types
  35: rustc::util::common::time
  36: rustc_typeck::check_crate
  37: rustc_interface::passes::analysis
  38: rustc::ty::query::__query_compute::analysis
  39: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::analysis<'tcx>>::compute
  40: rustc::dep_graph::graph::DepGraph::with_task_impl
  41: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  42: <std::thread::local::LocalKey<T>>::with
  43: rustc::ty::context::TyCtxt::create_and_enter
  44: rustc_driver::driver::compile_input
  45: <scoped_tls::ScopedKey<T>>::set
  46: rustc_driver::run_compiler
  47: <scoped_tls::ScopedKey<T>>::set
  48: syntax::with_globals
  49: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:87
  50: <F as alloc::boxed::FnBox<A>>::call_box
  51: std::sys::unix::thread::Thread::new::thread_start
             at /rustc/0ea22717a1e01fa535534b85a5347a7e49fc79de/src/liballoc/boxed.rs:759
             at src/libstd/sys_common/thread.rs:14
             at src/libstd/sys/unix/thread.rs:80
  52: start_thread
  53: __clone
query stack during panic:
#0 [typeck_tables_of] processing `<I as UnwrapItemsExt>::unwrap_items`
#1 [type_of] processing `<I as UnwrapItemsExt>::II`
#2 [collect_mod_item_types] collecting item types in top-level module
#3 [analysis] running analysis passes on this crate
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 (0ea22717a 2019-03-02) running on x86_64-unknown-linux-gnu

note: compiler flags: -C codegen-units=1 -C debuginfo=2 --crate-type lib

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

error: Could not compile `playground`.

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

[oli-obk]

probably related to #58817

[oli-obk]

cc @alexreg might not be impl-trait-in-let-binding related after all

[alexreg]

@oli-obk Ah, good to know. Are you going to tackle this? I'm not sure if the RFC for existential type should support this syntax (I suspect not), but it would be nice (for the sake of my upcoming PR) to support existential type within impls at an HIR level, at least.

[oli-obk]

I'm not sure if the RFC for existential type should support this syntax (I suspect not), but it would be nice (for the sake of my upcoming PR) to support existential type within impls at an HIR level, at least.

Existential types for associated types in trait impls are already supported and suggested to exist by the RFC. The issue here is probably that I never considered generics in that light.

Or am I misunderstanding what you mean by "this syntax"?

[alexreg]

Ah, I was probably thinking of the case of inherent impls... glad these are supported.

[JohnTitor]

The ICE doesn't appear on the latest nightly via the above link.

[alexreg]

Good spot. Not sure what PR fixed this, but I suspect it can be closed now... @Centril?

[JohnTitor]

Before closing this, we can add the tests for this.

[alexreg]

@JohnTitor It depends if there is already an equivalent (minimal) example. If there is, no need... if not, then yes (and let's minimise this one).