expr: prevent stack overflow on deeply nested parentheses

[koopatroopa787]

Summary

Deeply nested parentheses like (((...))) cause a stack overflow in expr because the recursive descent parser creates ~8 stack frames per paren level (one parse_simple_expression, one parse_expression, and six parse_precedence calls). At ~105 levels the default thread stack is exhausted, producing a process abort.

Fix

Added a depth: usize counter to the Parser struct. When parse_simple_expression encounters ( and self.depth >= MAX_RECURSION_DEPTH, it returns ExprError::RecursionLimit ("expression too deeply nested", exit code 2) instead of recursing further.

MAX_RECURSION_DEPTH = 86 caps the recursive stack at ~688 frames, providing comfortable headroom below the observed ~840-frame overflow threshold in debug builds.

Test

A new regression test test_deeply_nested_parens_do_not_crash passes 5000 levels of nesting to expr and verifies it exits with code 2 and prints the error message, rather than crashing.

Fixes #13146

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[codspeed]

Merging this PR will degrade performance by 3.29%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

❌ 2 regressed benchmarks
✅ 337 untouched benchmarks
⏩ 46 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	du_max_depth_balanced_tree[(6, 4, 10)]	25.5 ms	26.5 ms	-3.48%
❌	Simulation	du_all_wide_tree[(5000, 500)]	16.2 ms	16.8 ms	-3.1%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing koopatroopa787:fix-expr-stack-overflow-deep-parens (639b0d6) with main (76d7a53)²}

Footnotes

1. 46 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (67cc7a1) during the generation of this report, so 76d7a53 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[HackingRepo]

codspeed was actually saying invalid benchmarks, @sylvestre can we have a workaround a workflow that use hyperfine or similar, codspeed is reporting highly invalid results

[xtqqczze]

#13333 might be a better approach?

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/tail/symlink (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/date/date-locale-hour (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/misc/io-errors (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/tail/retry (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/tail/tail-n0f (passes in this run but fails in the 'main' branch)

[xtqqczze]

codspeed was actually saying invalid benchmarks, @sylvestre can we have a workaround a workflow that use hyperfine or similar, codspeed is reporting highly invalid results

The discrepancy comes from the different runtime environments (AMD EPYC 7763 64-Core Processor vs. Intel(R) Xeon(R) 6973P-C). Since GitHub Actions doesn’t provide consistent hardware across runners, this isn’t something we can realistically work around. In any case, since there were no changes to du, the benchmark discrepancies can be safely ignored.

[RenjiSann]

Will close since #13333 was merged