Repository navigation
bpo-40228: More robust frame.setlineno. - #19437
markshannon merged 4 commits into
Conversation
Sorry, something went wrong.
There was a problem hiding this comment.
Please put the { on its own line (PEP 7).
Sorry, something went wrong.
There was a problem hiding this comment.
Please check this call for failure.
Sorry, something went wrong.
There was a problem hiding this comment.
Please use PyBytes_GET_SIZE() here instead of PyBytes_Size().
Sorry, something went wrong.
There was a problem hiding this comment.
lines is leaked here.
Sorry, something went wrong.
There was a problem hiding this comment.
Please use PyBytes_GET_SIZE().
Sorry, something went wrong.
There was a problem hiding this comment.
PyBytes_AS_STRING().
PEP 7 states that no line should be longer than 79 characters.
Sorry, something went wrong.
There was a problem hiding this comment.
PyBytes_AS_STRING().
Sorry, something went wrong.
|
@ZackerySpytz thanks for the review |
Sorry, something went wrong.
|
Re-basing to force test re-run before merging. |
Sorry, something went wrong.
Makes no assumptions about the layout of bytecode.
Makes setting frame.f_lineno more robust and flexible.
To improve robustness, the code takes the simple, pragmatic approach: If it is safe to make the jump, then do so. We no longer attempt to decide if it "reasonable" or "sensible", merely if it is safe.
"Safe" in this context, means "won't crash the interpreter".
The increased flexibility is a side effect of this more pragmatic approach.
There are number of test cases where a jump is safe, but we disallowed it. Those cases are now allowed.
A couple of cases are now disallowed. Those involve jumping to unreachable code. Since we cannot compute the exception stack state for unreachable code, it is unsafe to jump to it.
Removing assumptions about the bytecode layout will allow us to enhance the compiler without worrying about breaking this code all the time.
Another point in favour of this PR is that it reduces the code size by about 80 lines.
https://bugs.python.org/issue40228