Repository navigation
fix: translate deeply nested files instead of overflowing the stack - #65
Merged
Merged
Conversation
ylluminate
force-pushed
the
fix-deep-nesting
branch
from
November 13, 2026 15:01
dd157db to
51a4c00
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
py2v crashed with
V panic: stack overflowon files that nest deeply: about 70 nested blocks, anif/elifchain of 70 branches (Python nests eachelifinside theelsebefore it), or one expression about 200 levels deep, such as a sum of 196 terms. The transpiler walks the tree by recursion on the main thread's stack. The crash can't be caught, so in--packageit ends the whole run.The work now runs on a thread with a 64 MiB stack, set with
#flag -DV_THREAD_STACK_SIZE=67108864, which V's generated C reads when it creates a thread (@[spawn_stack]had no effect when I tried it). The translation itself isn't touched.64 MiB is twice the smallest stack size I tested successfully. V's
json2rejects JSON deeper than 512 nested levels. For anelifchain that means 250 branches translate (with 32 MiB; 16 overflows) and 256 exit 1 withInvalid json: Syntax: exceeded the maximum nesting depth. Other shapes have other limits: a sum of 1001 terms exits 1 with aRecursionErrorfrom the frontend, which this doesn't change, as does sympy'spolys/numberfields/resolvent_lookup.py(569 levels). The macro applies to every thread V starts, so the--checkworkers get 64 MiB stacks too; on Windows, where a thread's stack size is committed up front, that is about 576 MiB with the default eight workers. I measured on macOS arm64 only.Separately, V refuses an expression nested more than 100 levels when it compiles the output (
expr level > 100), so a sum of 401 terms now translates to V that doesn't build.I ran into it on sympy, where
polys/polyquinticconst.py(230 levels) crashes on master and translates with this.Test plan
tests/run_tests.vsh: anelifchain of 120 branches and a sum of 401 terms must translate. Master's py2v exits 139 on both.elifchain builds and prints 5, as Python does.tests/give the same output and exit status with master's py2v and with this change.v tests/run_tests.vsh: 180 passed, 0 failed (178 before, plus the two checks).