Change:
debug!("constrain_opaque_type: def_id={:?}", def_id); debug!("constrain_opaque_type: opaque_defn={:#?}", opaque_defn); <ins> let tcx = self.tcx; </ins> let concrete_ty = self.resolve_type_vars_if_possible(&opaque_defn.concrete_ty); debug!("constrain_opaque_type: concrete_ty={:?}", concrete_ty); <del> let abstract_type_generics = self.tcx.generics_of(def_id); </del> <ins> let abstract_type_generics = tcx.generics_of(def_id); </ins> <del> let span = self.tcx.def_span(def_id); </del> <ins> let span = tcx.def_span(def_id); </ins> <del> // If there are required region bounds, we can just skip // ahead.  There will already be a registered region // obligation related `concrete_ty` to those regions. </del> <ins> // If there are required region bounds, we can use them. </ins> if opaque_defn.has_required_region_bounds { <ins> let predicates_of = tcx.predicates_of(def_id); debug!( "constrain_opaque_type: predicates: {:#?}", predicates_of, ); let bounds = predicates_of.instantiate(tcx, opaque_defn.substs); debug!("constrain_opaque_type: bounds={:#?}", bounds); let opaque_type = tcx.mk_opaque(def_id, opaque_defn.substs); let required_region_bounds = tcx.required_region_bounds( opaque_type, bounds.predicates.clone(), ); debug_assert!(!required_region_bounds.is_empty()); for region in required_region_bounds { concrete_ty.visit_with(&mut OpaqueTypeOutlivesVisitor { infcx: self, least_region: region, span, }); } </ins> return; }

Discussion:
Rustc 1.33 panicked while compiling a code that was working well on 1.32. I tried this code: This happened: : Backtrace:
After some testing, this is the lines that cause the compiler to crash.
can you post a reduced test case or the full source including and the module files?
Simple project that causes this:
Bisected, the cause of the regression is cc
: just did a test case (thanks!).
triage: P-high.
assigning to self based on stack trace and related work on region-vid conversion issues, and removing nomination tag.
Is this likely to be in a 1.33.1 release?
If we do a release and the fix is not risky to land in a point release probably yes, but there aren't other point release worthy issues to fix so I'm not sure if we'll end up doing one.
This is currently blocking us from updating to 1.33.
Judging from our code and the code above, it might be related to .
This project has been deleted. Can someone either repost it, or share a copy with me?
The comment below is now posted separately as . Not sure if it triggers the same bug, but I found this issue (in details below) while searching for a solution. <detailsThis code panics on 1.33 - 1.35, but does not panic on 1.32: On 1.32: On 1.35 nightly (today): </details--Bryan
based on the stack trace, I do not think that is the exact same bug. Thanks for investigating; Lets make sure to file a separate issue for it!
also, your code seems to be missing the definition for ? (I recommend posting reproduction in the playpen and seeing if they reproduce there, for ease of sharing and also catching little cut-and-paste omissions along the way.)
I probably should have pinged when I wrote that question. Let's seeing if pinging here helps.
Since the sample project that causes this was taken down, I guessed I will take an example from either or and use that as the basis for investigation going forward. in particular seems to have the best bet of having enough information (namely a dependencies section) to allow easy reproduction.
I've just checked on Rust 1.34.1 and I confirm the bug is still present.

and told me yesterday at the Paris meetup to bump this issue. I'll try to create a minimal testcase later today.
cc
Compiler triage: It seems like are still missing a case for reproduction?
do you still have a local checkout of repro?
by the way, were you able to create the minimal testcase you mentioned ?
nope :(
I created a simple (but not minimal) based on the initial comment, and checked it indeed ICEs on nightly with the expected "cannot convert to a region vid" error. I haven't tried minimizing or bisecting, however (but since very similar errors had been fixed by , I thought this issue here would have been fixed at the same time — so maybe it won't be bisected to the Universes PR after all). edit: I also ran a quick bisect on it, and it started ICEing (with a different error location) in which is IIRC the one where Universes landed). A minimization would be very helpful indeed.
if I change to no longer ICE (or if I inline ), I get this error. Do you think you can have a repro that doesn't error when the ICE is gone?
Got it:
Reduced: Since this involves IntoIterator, it makes me think of another recent ICE involving universes, but I can't find the exact issue right now.
Maybe ?
I manually checked the latest nightly on the bigger repro project, and we have the expected FnMut error instead of the ICE . The minimized code above (thanks again doesn't ICE either.