Is it a bad sign to have the 'reached the type-length limit' error while working with futures?

[bbigras]

I got this error from time to time in projets using futures. I just add the type_length_limit attribute and call it a day but I’m wondering if it should be avoided.

error: reached the type-length limit while instantiating `std::sync::Once::call_once::<[closure@DefId(44/1:587 ~ futures[b...`
  |
  = note: consider adding a `#![type_length_limit="2097152"]` attribute to your crate

[gbutler69]

I’d examine your design. It sounds like you might be doing too much of having a future, that returns a future, that returns a future, …

My guess is your’e doing something akin to infinite recursive function calls.

EDIT: I think I might be right. This might be relevant: https://github.com/rust-lang/rust/issues/38335

[jonh]

Avoiding an error message with long types is good for reading sanity. impl Trait to the rescue.

[vitalyd]

I’d love to see what the actual code looks like

[cuviper]

impl Trait to the rescue.

Doesn’t impl Trait make it easier to create such monsters? The full type is still created, just behind the scenes where you never have to write it.

You can break it up with dyn Trait though.

[vorner]

I’m afraid I’ve also hit this and I’m a bit worried. First, I’m not entirely sure what it means ‒ I mean I can guess it is kind of „you have composed a very complex type“, but what does that number specify?

Sure, the code is full of generic layers and impl Traits and closures wrapping other closures. It’s not all at one place, though, I hope each local part in itself is readable.

If anyone wants to have a look https://github.com/vorner/spirit/blob/master/spirit-hyper/examples/hws.rs (this is actually the thing using all the other levels, they crawle through the rest of the repository).

(Edit: changed the URL to point to master)

[vitalyd]

First, I’m not entirely sure what it means ‒ I mean I can guess it is kind of „you have composed a very complex type“, but what does that number specify?

It looks to be # of types involved in monomorphization.

From quick archaeology:

1. Issue first reported here
2. That leads to this change, which is the current code AFAICT

It is somewhat mind-bending how such large types can be so (seemingly) easy to create, when lots of generics are involved.