Skip to content
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

[3.7] bpo-36256: Fix bug in parsermodule when parsing if statements (GH-12477) #12488

Merged
merged 1 commit into from
Mar 21, 2019

Conversation

miss-islington
Copy link
Contributor

@miss-islington miss-islington commented Mar 21, 2019

bpo-36256: Fix bug in parsermodule when parsing if statements

In the parser module, when validating nodes before starting the parsing with to create a ST in "parser_newstobject" there is a problem that appears when two arcs in the same DFA state has transitions with labels with the same type. For example, the DFA for if_stmt has a state with
two labels with the same type: "elif" and "else" (type NAME). The algorithm tries one by one the arcs until the label that starts the arc transition has a label with the same type of the current child label we are trying to accept. In this case, the arc for "elif" comes before the arc for "else"and passes this test (because the current child label is "else" and has the same type as "elif"). This lead to expecting a namedexpr_test (305) instead of a colon (11). The solution is to compare also the string representation (in case there is one) of the labels to see if the transition that we have is the correct one.
(cherry picked from commit 9a0000d)

Co-authored-by: Pablo Galindo Pablogsal@gmail.com

https://bugs.python.org/issue36256

…GH-12477)

bpo-36256: Fix bug in parsermodule when parsing if statements

In the parser module, when validating nodes before starting the parsing with to create a ST in "parser_newstobject" there is a problem that appears when two arcs in the same DFA state has transitions with labels with the same type. For example, the DFA for if_stmt has a state with
two labels with the same type: "elif" and "else" (type NAME). The algorithm tries one by one the arcs until the label that starts the arc transition has a label with the same type of the current child label we are trying to accept. In this case, the arc for "elif" comes before the arc for "else"and passes this test (because the current child label is "else" and has the same type as "elif"). This lead to expecting a namedexpr_test (305) instead of a colon (11). The solution is to compare also the string representation (in case there is one) of the labels to see if the transition that we have is the correct one.
(cherry picked from commit 9a0000d)

Co-authored-by: Pablo Galindo <Pablogsal@gmail.com>
@pablogsal pablogsal merged commit 00eb97b into python:3.7 Mar 21, 2019
@miss-islington miss-islington deleted the backport-9a0000d-3.7 branch March 21, 2019 23:56
@miss-islington
Copy link
Contributor Author

@pablogsal: Status check is done, and it's a success ✅ .

1 similar comment
@miss-islington
Copy link
Contributor Author

@pablogsal: Status check is done, and it's a success ✅ .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants