-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
bpo-37500: Make sure dead code does not generate bytecode but also detect syntax errors #14612
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
bf70fa2
to
40530df
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this change still mark a function as a generator when using "if 0: yield"? Does it still detect syntax errors?
Victor, |
Yes and yes. |
…tted Add a new field to the compiler structure that allows to be configured so no bytecode is emitted. In this way is possible to detect errors by walking the nodes while preserving optimizations. Add a specific tests for dead blocks being optimized.
I have updated the PR adding more tests |
Thanks for making the requested changes! @markshannon: please review the changes made to this pull request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure that this is the best way, at least it is not simple, so I suggest to wait with its merging until we try other approaches.
* while visiting nodes. | ||
*/ | ||
|
||
#define BEGIN_DO_NOT_EMIT_BYTECODE { \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BEGIN_DO_NOT_EMIT_BYTECODE
and END_DO_NOT_EMIT_BYTECODE
always surround VISIT_SEQ
. I would add a new macros which expands to
c->c_do_not_emit_bytecode++;
VISIT_SEQ(...);
c->c_do_not_emit_bytecode--;
instead of BEGIN_DO_NOT_EMIT_BYTECODE
and END_DO_NOT_EMIT_BYTECODE
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will update the PR soon.
If you think there are better ways, I am happy to try them out :) @serhiy-storchaka Could you elaborate a bit more what you don't like about this approach? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I dislike the macros, but you keep them if you prefer.
This change looks like a nice way to fix https://bugs.python.org/issue37500
Thanks @pablogsal for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8. |
…tect syntax errors (pythonGH-14612) https://bugs.python.org/issue37500 Add a new field to the compiler structure that allows to be configured so no bytecode is emitted. In this way is possible to detect errors by walking the nodes while preserving optimizations. https://bugs.python.org/issue37500 (cherry picked from commit 18c5f9d) Co-authored-by: Pablo Galindo <[email protected]>
GH-14780 is a backport of this pull request to the 3.8 branch. |
Oh, I didn't want to merge directly the change, only say that it LGTM. I didn't want to merge it since @serhiy-storchaka seems to want to experiment another approach (that he didn't mention). I dislike automerge :-( |
I closed the 3.8 backport (without merging it), until we agree on what should be done. |
@serhiy-storchaka: Would you mind to elaborate why you consider that this change is "not simple"? It sounds like a simple and working solution to me. It don't see how we can produce SyntaxError without this approach (visit all nodes even the ones that we remove). |
I see no reason not to merge this into 3.8. |
Thanks @pablogsal for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8. |
GH-15002 is a backport of this pull request to the 3.8 branch. |
…tect syntax errors (pythonGH-14612) https://bugs.python.org/issue37500 Add a new field to the compiler structure that allows to be configured so no bytecode is emitted. In this way is possible to detect errors by walking the nodes while preserving optimizations. https://bugs.python.org/issue37500 (cherry picked from commit 18c5f9d) Co-authored-by: Pablo Galindo <[email protected]>
I am going to reopen the backport to 3.8 as I think is very important to test this before b4 so we can react accordingly if something goes wrong. If we discover a better version to do this, we can always backport it on top, but I think is very important to give the solution some exposure before the release candidates and the last beta. I will keep investigating for better solutions and maybe will do some refactors with some of the proposed ideas (like creating a wrapper for |
…tect syntax errors (GH-14612) https://bugs.python.org/issue37500 Add a new field to the compiler structure that allows to be configured so no bytecode is emitted. In this way is possible to detect errors by walking the nodes while preserving optimizations. https://bugs.python.org/issue37500 (cherry picked from commit 18c5f9d) Co-authored-by: Pablo Galindo <[email protected]>
…tect syntax errors (pythonGH-14612) https://bugs.python.org/issue37500 Add a new field to the compiler structure that allows to be configured so no bytecode is emitted. In this way is possible to detect errors by walking the nodes while preserving optimizations. https://bugs.python.org/issue37500
…tect syntax errors (pythonGH-14612) https://bugs.python.org/issue37500 Add a new field to the compiler structure that allows to be configured so no bytecode is emitted. In this way is possible to detect errors by walking the nodes while preserving optimizations. https://bugs.python.org/issue37500
https://bugs.python.org/issue37500
Add a new field to the compiler structure that allows to be configured
so no bytecode is emitted. In this way is possible to detect errors by
walking the nodes while preserving optimizations.
https://bugs.python.org/issue37500