Stop the expansion of decision trees for fixed slice patterns as soon as possible #17944
Conversation
ghost
changed the title
|
So something that actually did use a long array match pattern would still crash? I wouldn’t call this a complete fix if that’s still the case, though it’ll fix every serious case. But being able to cause stack overflow in the compiler at all from that is bad. |
|
Since Rust has bounded stacks, you're not going to be able to eliminate all stack overflows from the compiler unless the compiler never uses recursion bounded by its input. |
|
This is not the sort of thing that I at least would expect to be recursive. I can understand nested things becoming recursion, but an array? Not so much. |
|
@chris-morgan Well, what you're describing is not really specific to slices. Tuples, structs and variants also incur recursion of depth that grows with the number of elements/fields and fixed-length slices are really just a homogenous kind of tuples.
|
Doing so would incur deeply nested expansion of the tree with no useful side effects. This is problematic for "wide" data types such as structs with dozens of fields but where only a few are actually being matched or bound. Most notably, matching a fixed slice would use a number of stack frames that grows with the number of elements in the slice. Fixes #17877.
|
@alexcrichton I pushed a more general fix which will improve stack usage for all scenarios where you match a "wide" data type (a struct with several fields or a n-ary tuple with a high n) but only compare/bind a small subset of them. |
ghost
deleted the
Fixes #17877.