Neil Schemenauer <nas-pyt...@arctrix.com> added the comment: There is some more explanation in the PR and sample code.
We unwind, if we hit a finally fblock, we emit code of the body of it. If inside the block, there is another return statement, we unwind again. That causes an infinite loop in the compiler. The commit 0610860 is a fix, I think. I have a cleaner version but haven't pushed it yet. There are still some remaining bugs though, caused by "return" in the finally body. The problem as I see it is that "unwind_exception" in ceval pushes a EXCEPT_HANDLER fblock if we are inside a SETUP_EXCEPT or SETUP_FINALLY block. If there is a return in the finally body, the compiler doesn't know if it should POP_BLOCK or not. At least, that is my understanding now. I think the best way forward is to split this patch into multiple parts. I have a simple patch that changes fblockinfo to be a singly linked list (like blockinfo). Next, I think we could change the exception opcodes to have a fixed stack effect (don't think that requires unwind to be done by compiler). Rather than pushing three values for an exception, could we just build a tuple and push that? Seems simpler to me vs having ROT_FOUR. Finally, we can tackle the compiler based unwind. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17611> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
