Change:
def_id: DefId, ) -> bool { let trait_ref = ty::TraitRef::new(infcx.tcx, def_id, [ty]); <del> let obligation = Obligation::new(infcx.tcx, ObligationCause::dummy(), param_env, trait_ref); infcx.predicate_must_hold_modulo_regions(&obligation) </del> <ins> pred_known_to_hold_modulo_regions(infcx, param_env, trait_ref) } /// FIXME(@lcnr): this function doesn't seem right and shouldn't exist? /// /// Ping me on zulip if you want to use this method and need help with finding /// an appropriate replacement. #[instrument(level = "debug", skip(infcx, param_env, pred), ret)] fn pred_known_to_hold_modulo_regions<'tcx>( infcx: &InferCtxt<'tcx>, param_env: ty::ParamEnv<'tcx>, pred: impl ToPredicate<'tcx>, ) -> bool { let obligation = Obligation::new(infcx.tcx, ObligationCause::dummy(), param_env, pred); let result = infcx.evaluate_obligation_no_overflow(&obligation); debug!(?result); if result.must_apply_modulo_regions() { true } else if result.may_apply() { // Sometimes obligations are ambiguous because the recursive evaluator // is not smart enough, so we fall back to fulfillment when we're not certain // that an obligation holds or not. Even still, we must make sure that // the we do no inference in the process of checking this obligation. let goal = infcx.resolve_vars_if_possible((obligation.predicate, obligation.param_env)); infcx.probe(|_| { let ocx = ObligationCtxt::new(infcx); ocx.register_obligation(obligation); let errors = ocx.select_all_or_error(); match errors.as_slice() { // Only known to hold if we did no inference. [] => infcx.shallow_resolve(goal) == goal, errors => { debug!(?errors); false } } }) } else { false } </ins> } #[instrument(level = "debug", skip(tcx, elaborated_env))]

Discussion:
https://crater- This seems like a potential recurrence of , which was fixed in but lacked a test case.
searched nightlies: from nightly-2024-02-01 to nightly-2024-02-29 regressed nightly: nightly-2024-02-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed in -- cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
can revert the change from which caused this 2 weeks before this hits stable. We dshould really get a minimization of this issue though :/
(the cause should be this commit )
Interestingly, this builds on nightly. It seems to me that has fixed, or hid, the ICE .
Probably hidden; that's why we need an MCVE. If it has to do w/ a field not in a struct tail, a simple reordering of fields may trigger this bug again.
I'm not sure how small we can make it, but I've reduced this to a more reasonable size. I've ran out of steam on this if someone wants to help it cross the finish line if needed. It's still very convoluted, and more layers could be removed. It's quite fiddly though, removing a bound here or there makes the ICE disappear like a frightened turtle. The ICE is still present on nightly, but I lost track of the actual source while reducing : it used to happen in the collector but now a bit later. I hope it's fine, it's still in codegen and bisects to as well. <details<summaryThis is not a place of honor</summary</details
Reopening to track beta backport.
Backported in .