ICE when playing around with existential types, impl trait

[vandenheuvel]

This seems to be a regression from 1.45.0-beta.3 (2020-06-27 8196407f01018b442e80) to 1.46.0-nightly (2020-07-03 f844ea1e561475e60232).

The following (totally incorrect, nightly features dependent) code is rejected without an ICE on the mentioned beta version, but nightly handles this less gracefully.

trait Trait {
    type Associated;
    fn into(self) -> Self::Associated;
}

impl<'a, I: Iterator<Item = i32>> Trait for (i32, I) {
    type Associated = (i32, impl Iterator<Item = i32>);
    fn into(self) -> Self::Associated { (0_i32, &[0_i32].iter()) }
}

Backtrace

error: internal compiler error: src/librustc_mir/borrow_check/region_infer/mod.rs:691:13: member constraint for `DefId(0:10 ~ playground[4db5]::{{impl}}[0]::Associated[0]::{{opaque}}[0])` has an option region `'_#4r` that is not a universal region

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:916:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.51.al-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.51.al-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:217
  10: rustc_driver::report_ice
  11: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:524
  12: std::panicking::begin_panic
  13: rustc_errors::HandlerInner::bug
  14: rustc_errors::Handler::bug
  15: rustc_middle::util::bug::opt_span_bug_fmt::{{closure}}
  16: rustc_middle::ty::context::tls::with_opt::{{closure}}
  17: rustc_middle::ty::context::tls::with_opt
  18: rustc_middle::util::bug::opt_span_bug_fmt
  19: rustc_middle::util::bug::bug_fmt
  20: rustc_mir::borrow_check::region_infer::RegionInferenceContext::solve
  21: rustc_mir::borrow_check::nll::compute_regions
  22: rustc_mir::borrow_check::do_mir_borrowck
  23: rustc_infer::infer::InferCtxtBuilder::enter
  24: rustc_mir::borrow_check::mir_borrowck
  25: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::mir_borrowck>::compute
  26: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  27: rustc_data_structures::stack::ensure_sufficient_stack
  28: rustc_query_system::query::plumbing::get_query_impl
  29: rustc_typeck::collect::type_of::find_opaque_ty_constraints::ConstraintLocator::check
  30: rustc_hir::intravisit::walk_impl_item_ref
  31: rustc_hir::intravisit::walk_item
  32: rustc_typeck::collect::type_of::type_of
  33: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::type_of>::compute
  34: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  35: rustc_data_structures::stack::ensure_sufficient_stack
  36: rustc_query_system::query::plumbing::get_query_impl
  37: rustc_query_system::query::plumbing::ensure_query_impl
  38: <rustc_typeck::collect::CollectItemTypesVisitor as rustc_hir::intravisit::Visitor>::visit_item
  39: rustc_middle::hir::map::Map::visit_item_likes_in_module
  40: rustc_typeck::collect::collect_mod_item_types
  41: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::collect_mod_item_types>::compute
  42: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  43: rustc_data_structures::stack::ensure_sufficient_stack
  44: rustc_query_system::query::plumbing::get_query_impl
  45: rustc_query_system::query::plumbing::ensure_query_impl
  46: rustc_session::session::Session::track_errors
  47: rustc_typeck::check_crate
  48: rustc_interface::passes::analysis
  49: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::analysis>::compute
  50: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  51: rustc_query_system::query::plumbing::get_query_impl
  52: rustc_middle::ty::context::tls::enter_global
  53: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  54: rustc_span::with_source_map
  55: rustc_interface::interface::run_compiler_in_existing_thread_pool
  56: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

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.46.0-nightly (f844ea1e5 2020-07-03) running on x86_64-unknown-linux-gnu

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

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

query stack during panic:
#0 [mir_borrowck] borrow-checking `<(i32, I) as Trait>::into`
#1 [type_of] computing type of `<(i32, I) as Trait>::Associated::{{opaque}}#0`
#2 [collect_mod_item_types] collecting item types in top-level module
#3 [analysis] running analysis passes on this crate
end of query stack

Playground. Scanning the codebase gives the impression that this bug! can only be triggered when impl_trait_in_bindings is enabled. See #61773.

[vandenheuvel]

I updated the MCVE. @jonas-schievink doesn't this also need label:regression-from-stable-to-nightly?

[Dylan-DPC-zz]

Marked as p-medium based on the discussion

[nikomatsakis]

It might be nice to use cargo bisect-rustc to figure out when this regression occurred, in any case. Perhaps some in the cleanup crew wants to give it a whirl....?

@rustbot ping cleanup

[rustbot]

Hey Cleanup Crew ICE-breakers! This bug has been identified as a good
"Cleanup ICE-breaking candidate". In case it's useful, here are some
instructions for tackling these sorts of bugs. Maybe take a look?
Thanks! <3

cc @AminArria @camelid @chrissimpkins @contrun @DutchGhost @elshize @ethanboxx @h-michael @HallerPatrick @hdhoang @hellow554 @imtsuki @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @senden9 @shekohex @sinato @spastorino @turboladen @woshilapin @yerke

[hellow554]

searched nightlies: from nightly-2020-06-10 to nightly-2020-07-02
regressed nightly: nightly-2020-06-16
searched commits: from 4fb54ed to f315c35
regressed commit: ce6d3a7

bisected with cargo-bisect-rustc v0.5.2

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc github --regress ice 

@rustbot modify labels: -E-needs-bisection

CC #72080 @matthewjasper

[nikomatsakis]

Thanks @hellow554, that makes sense...

[vandenheuvel]

Here is another example that triggers this ICE.