Fix: Handle if-else branches both ending with RETURN in decompiler#91
Open
cennn wants to merge 2 commits intothuml:masterfrom
Open
Fix: Handle if-else branches both ending with RETURN in decompiler#91cennn wants to merge 2 commits intothuml:masterfrom
cennn wants to merge 2 commits intothuml:masterfrom
Conversation
When torch.compile generates bytecode where both if/else branches end with RETURN_VALUE (no fall-through jump), generic_jump_if computed end_index == jump_index, leaving the else-body range empty. The else-body was then decompiled as sequential code with the wrong stack state, causing BUILD_LIST to encounter a Python None (from LOAD_GLOBAL's NULL marker) and crash with TypeError. Fix: detect when end_index == jump_index and the if-body ends with RETURN/RAISE, then extend the else-body range to cover the actual else branch so it gets decompiled with the correct stack context.
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
1 participant
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.
Root Cause
generic_jump_if uses a single end_index to define both if/else body boundaries. When if-body ends with RETURN_VALUE (common in torch.compile bytecode), no JUMP_FORWARD exists → end_index = jump_index, making the else-body range empty. The decompiler then propagates if_end_stack (contaminated with None) instead of jump_stack to the main loop, causing a TypeError in subsequent BUILD_LIST operations (attempting to join None with strings).
Expected Behavior
The decompiler should extend the else-body range to the function end when if-body ends with RETURN/RAISE, use jump_stack for else-body decompilation, and complete without errors for torch.compile bytecode (producing valid Python code).
Additional Context
This bug only affects torch.compile/synthetic bytecode:
torch.compile leaves extra stack elements before conditional jumps (normal Python bytecode has an empty stack post-condition pop).
torch.compile generates if/else branches ending with RETURN_VALUE (no merge-point JUMP_FORWARD).
Normal Python bytecode avoids the bug because empty stack state masks incorrect stack propagation.