Change:
&self, obligation: &PredicateObligation<'tcx>, ) -> bool { <del> self.evaluate_obligation(obligation) == EvaluationResult::EvaluatedToOk </del> <ins> self.evaluate_obligation_no_overflow(obligation) == EvaluationResult::EvaluatedToOk </ins> } <del> // Helper function that canonicalizes and runs the query, as well as handles // overflow. fn evaluate_obligation( </del> <ins> /// Evaluate a given predicate, capturing overflow and propagating it back. pub fn evaluate_obligation( </ins> &self, obligation: &PredicateObligation<'tcx>, <del> ) -> EvaluationResult { </del> <ins> ) -> Result<EvaluationResult, OverflowError> { </ins> let mut _orig_values = SmallVec::new(); let c_pred = self.canonicalize_query(&obligation.param_env.and(obligation.predicate), &mut _orig_values); // Run canonical query. If overflow occurs, rerun from scratch but this time // in standard trait query mode so that overflow is handled appropriately // within `SelectionContext`. <del> match self.tcx.global_tcx().evaluate_obligation(c_pred) { </del> <ins> self.tcx.global_tcx().evaluate_obligation(c_pred) } // Helper function that canonicalizes and runs the query. If an // overflow results, we re-run it in the local context so we can // report a nice error. fn evaluate_obligation_no_overflow( &self, obligation: &PredicateObligation<'tcx>, ) -> EvaluationResult { match self.evaluate_obligation(obligation) { </ins> Ok(result) => result, Err(OverflowError) => { let mut selcx = SelectionContext::with_query_mode(&self, TraitQueryMode::Standard); selcx.evaluate_obligation_recursively(obligation) <del> .expect("Overflow should be caught earlier in standard query mode") </del> <ins> .unwrap_or_else(|r| { span_bug!( obligation.cause.span, "Overflow should be caught earlier in standard query mode: {:?}, {:?}", obligation, r, ) }) </ins> } } }

Discussion:
Steps to reproduce:
I assume this is the same as
Running into this as well when running on 1.30.0-nightly ( 2018-08-05)
Hit this on the newest nightly ( 2018-08-18)
Same issue, slightly different line number Filtered log:
any idea what's going on here? let us know if you need T-compiler help :)
I didn't check yet, still on my todo list. I'll give it a look this week-end.
It would be great to have a minimized example here =)
True, I'll try to make one.
I think this is the same as as well
visited for triage. PR just needs to be landed.
Reopening; since we never backported , rustdoc ICE's on typenum again.
visiting for triage. It looks like PR is on target to be backported to stable. (In fact, the recent update of the labels to say just leads me to assume that the backport has occurred... yes, it was part of PR )
So, only two questions I have now: I openly mused to myself during this triage session that the failure to backport to beta sooner may represent a process failure of some sort. But there may be a very simple fix: Can/should we revise bors to not autoclose issues that are tagged as stable-to-beta or stable-to-stable regressions? Filed as barosl/homu On the subject of closing: Can we close this issue in light of ? Or do we need to wait until the 1.30.1 point release has officially been deployed?
Closed since 1.30.1 was released already.