I got a few errors that instructed me to increase my
1394658. What is the unit of this setting? Should I be worried about running into this soft-limit?
@Jake Goulding https://github.com/rust-lang/rust/blob/master/src/librustc/middle/recursion_limit.rs
It looks like the default is 1048576
@Zexbe ok, but what is the unit of this setting? Should I be worried about running into this soft-limit?
The unit is types. So
u32 has length 1,
Vec<u32> has length 2 (
Vec(u32, u32)> has length 4 (
wow, so 1048576 is really big then
Futures code can fairly easily hit this limit (it's after monomorphization and sees through impl trait). You may want to consider strategic use of
@Matthew Jasper hmm; why does the limit exist?
To avoid really slow codegen.
@centril thanks for the docs, but I don't see how it correlates to what @Matthew Jasper says:
maximum number of type substitutions
u32 a "type substitution"?
since it's after monomorphization, it doesn't seem to be about preventing non-termination in e.g. the trait system
No, that's what the recursion limit is for.
oh; it's used for traits as well, not just macros
and recursive monomorphizations, etc.
@Matthew Jasper I don't suppose there's an issue about improving the error to guide us to a judicious use of boxing?
type_length_limit somehow related to the linker and avoiding literally too long type names in debuginfo?
I don't think so. There may be a more general issue about tracking sizes of async futures.
@centril is the "really slow codegen" answer insufficient a reason?
ah, I missed matthew's answer
Is there a rough relation of number of types to compilation time? Like, if the default were 1M and I "needed" 100M (made up numbers), what kind of pain would I be feeling?
/me ponders whether storing generator witnesses out of line to reduce the impact of this would make any sense