Describe the bug
Pest grammars can cause overflow within Pest itself.
Pest previously introduced set_call_limit to limit the total size of expressions, but this doesn't affect program stack depth.
That setting can't be used to solve this problem, as setting it to a small value would prevent parsing interesting "wide" expressions.
To Reproduce
Here's a tiny illustrative grammar. On Windows, with the default 1Mb of stack space, it fails on my machine with 300 nested parenthesis, though this limit is far lower on a more realistic grammar.
WHITESPACE = _{ " " | "\t" | "\n" | "\r" }
expression = { SOI ~ add_expr ~ EOI }
add_expr = { mul_expr ~ ("+" ~ mul_expr)* }
mul_expr = { primary ~ ("*" ~ primary)* }
primary = { number | "(" ~ add_expr ~ ")" }
number = @{ ASCII_DIGIT+ }
Expected behavior
In a perfect world, parsing wouldn't be recursive. Barring that, being able to control max recursive depth would allow users to avoid this class of issue.
Describe the bug
Pest grammars can cause overflow within Pest itself.
Pest previously introduced set_call_limit to limit the total size of expressions, but this doesn't affect program stack depth.
That setting can't be used to solve this problem, as setting it to a small value would prevent parsing interesting "wide" expressions.
To Reproduce
Here's a tiny illustrative grammar. On Windows, with the default 1Mb of stack space, it fails on my machine with 300 nested parenthesis, though this limit is far lower on a more realistic grammar.
Expected behavior
In a perfect world, parsing wouldn't be recursive. Barring that, being able to control max recursive depth would allow users to avoid this class of issue.