parser: "expression nesting too deep" never reaches the first-error recorder (LSP/--lint show a cascade instead)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 78/100
Research direction
Start in src/parser.c at the PARSE_MAX_DEPTH guards in parse_unary and parse_expression, then run the deep.eigs reproduction with --lint --json. Add regression coverage in tests/test_lsp.py or the --lint suite for the current-token location, message, length, and precedence when both limits trip; done means the reported error is expression nesting too deep and the existing #943 f-string checks still pass.
Written by the indexing model from the issue text.
Description
Repro
python3 -c "print('x is ' + '(' * 300 + '1' + ')' * 300)" > deep.eigs
src/eigenscript deep.eigs # stderr: Parse error line 1: expression nesting too deep (plus cascades)
src/eigenscript --lint --json deep.eigs
--lint --json and the LSP publish only the first recorded error. The PARSE_MAX_DEPTH guards in parse_unary and parse_expression (src/parser.c) call fprintf and g_parse_errors++, but never eigs_record_first_error*. As a result, the published diagnostic is whatever recovery cascade comes after it (for example expected ')', got '('), not the actual cause. I found this while working on #1331 (the 65-level f-string case from #943).
Done when
- Both
PARSE_MAX_DEPTHguards record the error at the current token's line and column (and length). -
--lint --jsonon the repro reportsexpression nesting too deepas its error, not a cascade. - A regression test in tests/test_lsp.py (or the --lint suite) fails with the fix reverted.
- The #943 f-string depth checks in tests/test_lsp.py still pass. Decide which message wins when both limits trip on one line, and write that decision in the test.
- Dominant language
- C
- Stars
- 3
- Forks
- 7
- Avg merge
- 4h 15m
- Merged PRs (30d)
- 106
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from InauguralSystems/EigenScript
-
area:lint-tooling bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
InauguralSystems/EigenScript#1340 ·
Maintainers usually reply within 1 day
-
area:stdlib found-by:code-review kind:silent-wrong
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
InauguralSystems/EigenScript#1338 ·
Maintainers usually reply within 1 day
-
area:lint-tooling found-by:critic kind:docs-drift
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
InauguralSystems/EigenScript#1335 ·
Maintainers usually reply within 1 day
-
area:ci found-by:critic kind:gate-defect
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
InauguralSystems/EigenScript#1311 ·
Maintainers usually reply within 1 day
-
enrolment: decide test_gc_runner_controls.py (exempt vs enrol) and whether floors need a ratchetOpenarea:gates found-by:critic kind:decision
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
InauguralSystems/EigenScript#1280 · 1 comment ·
Maintainers usually reply within 1 day
All issues in InauguralSystems/EigenScript
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
microsoft/ebpf-for-windows#5604 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
AcademySoftwareFoundation/openexr#2683 ·
Maintainers usually reply within 1 day