reached the type-length limit while instantiating

[Thinkofname]

I started to get the following error with my nightly builds around two days ago:

error: reached the type-length limit while instantiating `<std::iter::Filter<I, P> as std::iter::Iterator><std::iter::Enum...`
  |
  = note: consider adding a `#![type_length_limit="2097152"]` attribute to your crate

Using cargo-bisect-rustc I got the following commit f565cdd and after building rustc manually I got down to this #58730 PR.

After poking around my project I found the keys method in here https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=151ab7543368e8ad2dbf3ff8c2a8e361 was causing the issue (stubbing out the method fixed the error) but I haven't been able to reproduce this outside of my codebase (this code is used as a separate crate)

Following the note on the error causes the error still to happen until increasing it to #![type_length_limit="8388608"]

Sorry I can't be more helpful with a way to reproduce this at the moment

[jonas-schievink]

This might be expected, since types used internally can change without notice, and your code might have been getting pretty close to the length limit even before that. Are you chaining/nesting a lot of types (iterators or futures)?

[Thinkofname]

I use iterator chains quite a bit.

The thing that confused me was why doubling the limit to 2097152 wasn't enough and I had to go all the way to 8388608 which seems like a huge jump.

[Thinkofname]

Played around on the playground and got this silly example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d4405d401041ec7a95f4bae94a32361f

On stable this compiles but on nightly you have to increase the type length limit past the initial suggestion all the way to 4964344. So chances are I have something similar in my code (filter inside a filter) and changes are just amplified in my case.

[pnkfelix]

potentially related to #54540

[pnkfelix]

assigning P-high for now since this is a stable-to-beta regression.

Given that its already been narrowed down to PR #58730 ... this may be a T-libs issue rather than T-compiler one? Not sure.

[pnkfelix]

I would normally also remove the nomination tag, since I do not think there is much for T-compiler to discuss here apart from the severity of the regression.

But since it is potentially related to #54540, I figured I'll leave the nomination tag for now, just to help ensure that when we discuss #54540, we will hopefully remember to take note of this issue (#58952) as well.

[pnkfelix]

triage: Under assumption that this is duplicate of #54540, I'm going to downgrade this to P-medium and remove the nomination tag.

[lcnr]

Afaict this issue can now be closed as the blowup of iterator adapters has been reduced and #54540 is used to track the more general problem.