There needs to be some way to debug exploding type lengths

[canndrew]

I've written a library and a small example program using the library. The example wouldn't compile until I increased the type_length_limit by several orders of magnitude, after which it took 20min to compile. I've managed to get this down to 5min by fiddling with the library API to make it a bit less generic, but that's still impractically long and I don't know what to try next.

I've written a lot of generic/async code before and this is far from the first time I've had this problem. For me at least, exploding compile times always correlate with exploding type lengths, so I need a way to find out where these massively complicated types are coming from.

The compiler's error message isn't much help here:

error: reached the type-length limit while instantiating `std::future::from_generator::<[s...td::future::Future, ()}]>, ()}]>`
   |
   = note: consider adding a `#![type_length_limit="109605624"]` attribute to your crate

error: aborting due to previous error

Is there some way to get it to not truncate the name of the type? Even if the fully-expanded type is a million lines long I could still pipe cargo's output to a file (or use less) and have a look at what the type actually is. Then maybe I could figure out where it's getting instantiated.

Are there any secret compiler options to do this? If so, the error message should probably suggest them to the user. More generally, are there any planned features to help users debug these kinds of problems (assuming that exploding type-complexity problems are inherent to rust's design and will be around forever)?

[kinnison]

Based on your paste I'd guess you have a function which were it not async would have surprisingly large stack use and thus now has a large generated future. Perhaps somewhere you have a [usize;4*1024*1024] or somseuch where a Vec<usize> which you then extended out to that size would put it on the heap instead and thus out of the generated future.

I concur though that it'd be good if the error pointed at where it was instantiating that from.

[ratmice]

It would be nice if instead of trying to expand the type out to a printable string, if there were a mechanism to dump a graph representation of the type substitutions rather than tryng to show and truncating the actual expansion after substitutions have been made.

[cuviper]

I've had some luck with increasing type_length_limit until it compiles, then looking at --emit=llvm-ir to find some of the really long symbols. It seems the longest ones don't always make it to output, but there may still be enough to see what area of code is so long.