Change:
let recursion_limit = *selcx.tcx().sess.recursion_limit.get(); if obligation.recursion_depth >= recursion_limit { debug!("project: overflow!"); <del> selcx.infcx().report_overflow_error(&obligation, true); </del> <ins> return Err(ProjectionTyError::TraitSelectionError(SelectionError::Overflow)); </ins> } let obligation_trait_ref = &obligation.predicate.trait_ref(selcx.tcx());

Discussion:
After is fixed now, I've tried to build diesels documentation and failed with the following error: Note that a normal build of diesel succeeds and also all doc tests are passing. rustc version: rustc 1.30.0-nightly ( 2018-09-22) rustdoc version: rustdoc 1.30.0-nightly ( 2018-09-22) diesel version:
This breaks the documentation for all crates which depend on diesel too, unless you run with
Is there anything I can do to help to debug/fix this?
I've played a bit further around with this. That strange thing is that it seems to depend on feature flags on diesel. and works fine. Any of , , and fails with the error posted above. So given the structure of the diesel code base the feature with the smallest impact is "32-column-table" because it is used only in . This macro is used to implement various traits for tuples of different sizes. The number in the front indicates the number of tuple elements. Toying around with this has shown that documentation builds fine (if only this feature is passed) as long as we generate those impl for tuples up to 16 elements. For bigger tuples building the documentation fails. That seems strange.
Is this the same as ?
Seems to be the same underlying issue, but it should be noted that this happens for me on the 2015 edition. (So it is probably not dependent on the edition.) Also a occurs if someone tries to build diesel with on windows using the or the toolchain. Surprisingly this does not happen . For me it seems to be quite strange that some trait resolution thing seems to be depended on the os used to compiling the crate in absent of any os specific impls.
I've played around a bit more and tried to get working on diesel. Turns out that some traits makes it building and documenting. I've no clue why, because those traits are not connected to that is mentioned in the error message in any way. I'm totally willing to dig into this event deeper, but I've no idea where to look for what so it would be great if anyone is willing to provide some guidance for this.
I've tried to play with to find the point where this error was introduced in rustdoc.

(This happens also on released diesel (1.3.0) versions, where rustdoc was working at release time.) This points to somewhere between 07-24 and 07-30 (Unfortunately there are no nightly's in between) This results in the following commit range Rustdoc related commits: Blind guess without any future investigation: It is related to ? cc as author of that commit
It's very likely but it was supposed to be fixed by cc
comment sounds that this also requires some changes in rustdoc. Are they already done? Is there anything other I can do to help solving this? (This is basically blocking diesel doing a release )
Ah indeed. Opening an issue to keep it in mind.
Opened .
Unfortunately, as said in this , problem doesn't lie in rustdoc but still in rustc. Or maybe I missed something else? cc
Sorry, missed these notifications. I will add to my list to investigate.
This is a stable-to-stable regression: worked in 1.29.2 and broken in 1.30.0.
cc can we get this fixed soon?
I'm looking into it <details<summaryBacktrace</summary</details
I managed to get that one failure ironed out, now rustdoc is failing with which I think is completely unrelated and should be fixed by diesel
Yes that's totally a issue with diesels documentation. I should have a patch for this somewhere in my local diesel clone, I will push that patch as soon as I've found it :wink:
visited for T-compiler triage. marking P-high. It has a PR and and have been repeatedly trying to get it to land successfully...
This is going to be fixed in 1.30.1, which should be released in minutes.
I can confirm that this is fixed with the 1.30.1 release
So the backport landed before the original PR’s code in master ...???
I think I figured it out what happened. This indeed appears fixed on stable, but still exists on master to best of my knowledge
The fix was not landed in master, but this particular issue just doesn't exist on stable yet.
I've beta nominated and accepted as well per the marking here (stable/beta regression).
Still needs a backport
landed, so this is done, right?
Yep.