[all changes are in parso/python/errors.py]
* utility function (`_get_namedexpr`) extracting all assignment expression (`namedexpr_test`) nodes
* add `is_namedexpr` parameter to `_CheckAssignmentRule._check_assignment` and special error message for assignment expression related assignment issues (*cannot use named assignment with xxx*)
* add assignment expression check to `_CompForRule` (*assignment expression cannot be used in a comprehension iterable expression*)
* add `_NamedExprRule` for special assignment expression checks
- *cannot use named assignment with lambda*
- *cannot use named assignment with subscript*
- *cannot use named assignment with attribute*
- and fallback general checks in `_CheckAssignmentRule._check_assignment`
* add `_ComprehensionRule` for special checks on assignment expression in a comprehension
- *assignment expression within a comprehension cannot be used in a class body*
- *assignment expression cannot rebind comprehension iteration variable 'xxx'*
* ENH: update grammar for py39
Grammar is copied from cpython commit
b4e68960b90627422325fdb75f463df1e4153c6e
There appears to be 3 new tokens in the grammar (ASYNC, AWAIT, and
TYPE_COMMENT)
* MNT: revert back to py38 grammar as py39 grammar pt1: comments
Looks like upstream has added some comments, remove them
* MNT: remove TYPE_COMMENT added upstream
* MNT: add string / fstring related changes from parso 38 grammer
* MNT: remove changes to support upstream grammar file
Under the old implementation,
```
outer: A [inner] B C
inner: B C [inner]
```
wouldn't get detected as the ambiguous grammar that it is, whereas
```
outer: A rest
rest: [inner] B C
inner: B C [inner]
```
would.
This would manifest itself as non-determinism in the DFA state
generation. See the discussion #62 on for a full explanation.
This modifies the ambiguity detection to work on a broader class of
issues, so it should now hopefully detect all cases where the given
grammar is ambiguous.
At some point, we could extend this logic to allow developers to
optionally set precedence of grammar productions, which could resolve
ambiguities, but that's not a strict requirement for parsing python.
Line continuation characters are valid inside of strings, but weren't
handled correctly in certain cases with f-strings, due to some small
tokenizer bugs.
This pull request to address those issues, and adds tests to validate
the new logic.
Dave Halter