Change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --() <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: This is also present in beta and nightly versions, but it is not present on 1.55.0 stable. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
56.0 is released on stable, and it ICEs there as well. label regression-from-stable-to-stable
Bisection led to nightly-2021-07-26. Automatic commit bisection failed. Manual commit bisection: Regression comes from .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Oops. Sorry for creating this ICE. I haven't really dig into this issue yet, but from the description, it seems this ICE comes from where the equality should be within a certain call, but didn't because of the HRTB region. This inequality is because the two parameters comes from two different routes. The first comes from iterator, which is called from The second comes from generator, which lived in , i think the call is the real difference here. This is my current theory, and i'll try to validate it with debugging rustc this week. I'm not totally sure what's the best way to fix this. I think maybe could give me some advice dealing with HRTBs here?
By the way, i've printed out the contents of the vtable for :
Should it just use ? Or I guess it needs the too... Hmm, probably since this is around codegen, we need to erase regions in both trait refs. But, I'd like to see what the two trait refs are.
is and is So... They're the same with , but inequal? I'm a little confused... So i switched to use , and they're a little different: is and is Complete diagnostics output:
This could "just" be fixed by anonymizing both trait refs. The here is not the same as here . I have to remember how we deduplicate these predicates elsewhere.
Created for erasing regions before comparison. Let me know if there's a more proper approach, and i'll update the pr accordingly.
Anyone think this needs a backport?

Discussion:
) -> usize { let (trait_to_be_found, trait_owning_vtable) = key; <ins> // #90177 let trait_to_be_found_erased = tcx.erase_regions(trait_to_be_found); </ins> let vtable_segment_callback = { let mut vtable_base = 0;

vtable_base += COMMON_VTABLE_ENTRIES.len(); } VtblSegment::TraitOwnEntries { trait_ref, emit_vptr } => { <del> if trait_ref == trait_to_be_found { </del> <ins> if tcx.erase_regions(trait_ref) == trait_to_be_found_erased { </ins> return ControlFlow::Break(vtable_base); } vtable_base += util::count_own_vtable_entries(tcx, trait_ref);

<ins> // check-pass trait Base<'f> { type Assoc; fn do_something(&self); } trait ForAnyLifetime: for<'f> Base<'f> {} impl<T> ForAnyLifetime for T where T: for<'f> Base<'f> {} trait CanBeDynamic: ForAnyLifetime + for<'f> Base<'f, Assoc = ()> {} fn foo(a: &dyn CanBeDynamic) { a.do_something(); } struct S; impl<'a> Base<'a> for S { type Assoc = (); fn do_something(&self) {} } impl CanBeDynamic for S {} fn main() { let s = S; foo(&s); } </ins>