Thomas B

Maybe related: https://github.com/rust-lang/rust/issues/20304

Thanks a lot for your answer! > It could also be related to [rust-lang/rust#99188](https://github.com/rust-lang/rust/issues/99188) which also has exponential behavior (if associated types, and big wrapped items are involved, which I'm...

> * Now if I **just** modify the other function Incremental compilation cache is actually pretty smart here: if you modify the value in the println, or the value of...

> The following changes do result in large check times: > * Adding/removing a `println!` statement to `different_each_regen` So it looks like you did succeed to reproduce my results. :)...

About notably fourth block: Looks like the fields of the table (even if unused afterwards) intervene a lot here. Removing them from there by doing something similar to this: https://github.com/Ten0/diesel/commit/b4fcea001f7cfc76098f2174e79521aeff74d79b...

So I started the work on this again today, findings/recap: We have 3 separate sub-issues: 1. Diesel has the compiler check a ton of trait bounds when building a plain...

> Just wanted to thank you on this investigation. I've been subscribed to this issue because I have a production codebase suffering from this typeck issue as well. Thank you!...

> feature flagging or `table!` setting @weiznich any strong preference for either of these two?

> Sorry to say that, but I would like to avoid both. In my opinion it is a really bad idea to make this behaviour configurable, as it makes it...

I've pushed to your `speedup_compile_times_for_joins` one extra commit that was required to make stuff like this compile: ```rust let q = schema::some_table_1::table .inner_join(schema::some_table_2::table) .inner_join(schema::some_table_3::table.inner_join(schema::some_table_4::table)); ``` With this additional change I...