| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
I think we should also do the same in the AST validator, otherwise this would lead an interpreter crash on the debug mode when the user tries to compile a malformed AST node object.
>>> tree = ast.parse("a = 1")
>>> tree.body[0].lineno = 0
>>> compile(tree, "<test>", "exec")
python: Python/Python-ast.c:2118: _PyAST_Assign: Assertion `p->lineno != 0 && p->lineno <= p->end_lineno' failed.
[1] 26880 IOT instruction (core dumped) ./python
Sorry, something went wrong.
|
Or maybe we should only limit this to nodes created by the parser. WDYT @pablogsal? Otherwise, I feel like it might break some code (even though it is clearly invalid). For example this now works, but if we start validating the line numbers for user created ASTs it will stop working: >>> tree = ast.parse("a = 1")
>>> tree.body[0].lineno = -3121
>>> code = compile(tree, "<test>", "exec")
>>> ln = {}
>>> exec(code, ln)
>>> ln["a"]
1
|
Sorry, something went wrong.
I'm preparing the other PR as we speak :) I still prefer to keep these separated as the other PR fixes a reported issue with pytest |
Sorry, something went wrong.
|
@isidentical Hummmmm there is an ordering problem here. We create the C nodes before we validate them, so the assert will trigger before we can raise a nice exception. Maybe we should add the check only on the validation step..... what do you think? There is a separate problem which is that end_line_number defaults to 0, but if the user is setting just the line number currently then that leaves the node as invalid. I plan to add a check in the AST constructor to correct this, but we can just say "well, that's invalid now". |
Sorry, something went wrong.
|
I have changed to PR to just adding the check in the AST validator. |
Sorry, something went wrong.
I think that's definietly better (and since we are running the validator on debug mode even for the regular parser outputs, I think it should cover all the bases). |
Sorry, something went wrong.
|
Should we drop the backport labels since this is theoritically a breaking change @pablogsal? Otherwise it LGTM (with a news entry). |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM (though there might be some missing cases for the validation , like excepthandler?)
Sorry, something went wrong.
| return 0; \ | ||
| } \ | ||
| if ((node->lineno < 0 && node->end_lineno != node->lineno) || \ | ||
| (node->col_offset < 0 && node->col_offset != node->end_col_offset)) { \ |
There was a problem hiding this comment.
NIT:
| (node->col_offset < 0 && node->col_offset != node->end_col_offset)) { \ | |
| (node->col_offset < 0 && node->col_offset != node->end_col_offset)) { \ |
Sorry, something went wrong.
For 3.10 yes, but for 3.11 no because failing to do this causes the compiler to break. |
Sorry, something went wrong.
I added two more in the last commit. |
Sorry, something went wrong.
|
Thanks @pablogsal for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11. |
Sorry, something went wrong.
|
GH-93360 is a backport of this pull request to the 3.11 branch. |
Sorry, something went wrong.
…by the parser is always consistent (pythonGH-93352) (cherry picked from commit 5893b5d) Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
| Back | FazBrowse Home | New Git URL |
Closes: #93351