Limits
The following attributes affect compile-time limits.
The recursion_limit attribute
The recursion_limit attribute may be applied at the crate level to set the
maximum depth for potentially infinitely-recursive compile-time operations
like macro expansion or auto-dereference.
It uses the MetaNameValueStr syntax to specify the recursion depth.
Note
The default in
rustcis 128.
#![allow(unused)] #![recursion_limit = "4"] fn main() { macro_rules! a { () => { a!(1); }; (1) => { a!(2); }; (2) => { a!(3); }; (3) => { a!(4); }; (4) => { }; } // This fails to expand because it requires a recursion depth greater than 4. a!{} }
#![allow(unused)] #![recursion_limit = "1"] fn main() { // This fails because it requires two recursive steps to auto-dereference. (|_: &u8| {})(&&&1); }
The type_length_limit attribute
The type_length_limit attribute sets the maximum number of type substitutions allowed when constructing a concrete type during monomorphization.
Note
rustconly enforces the limit when the nightly-Zenforce-type-length-limitflag is active.For more information, see Rust PR #127670.
Example
#![type_length_limit = "4"] fn f<T>(x: T) {} // This fails to compile because monomorphizing to // `f::<((((i32,), i32), i32), i32)>` requires more // than 4 type elements. f(((((1,), 2), 3), 4));
Note
The default value in
rustcis1048576.
The type_length_limit attribute uses the MetaNameValueStr syntax. The value in the string must be a non-negative number.
The type_length_limit attribute may only be applied to the crate root.
Note
rustcignores use in other positions but lints against it. This may become an error in the future.
Only the first use of type_length_limit on an item has effect.
Note
rustclints against any use following the first. This may become an error in the future.