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

ICE in typeck on existential return type in trait #58887

Open
athre0z opened this Issue Mar 3, 2019 · 5 comments

Comments

Projects
None yet
4 participants
@athre0z
Copy link

athre0z commented Mar 3, 2019

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 oli-obk self-assigned this Mar 3, 2019

@oli-obk

This comment has been minimized.

Copy link
Contributor

oli-obk commented Mar 3, 2019

probably related to #58817

@oli-obk

This comment has been minimized.

Copy link
Contributor

oli-obk commented Mar 3, 2019

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

@alexreg

This comment has been minimized.

Copy link
Contributor

alexreg commented Mar 3, 2019

@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

This comment has been minimized.

Copy link
Contributor

oli-obk commented Mar 4, 2019

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

This comment has been minimized.

Copy link
Contributor

alexreg commented Mar 4, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.