I just noticed a subtle discrepancy between the old parser and the PEG parser.

Consider this syntax error:
```
if x {a}: pass
```
The old parser places the caret at the '{':
```
$ python3.8 -c 'if x { a } : pass'
  File "<string>", line 1
    if x { a } : pass
         ^
SyntaxError: invalid syntax
```
The PEG parser puts it at 'a':
```
$ python3.10 -c 'if x { a } : pass'
  File "<string>", line 1
    if x { a } : pass
           ^
SyntaxError: invalid syntax
```

I don't think we should put much effort into fixing it -- it's just a curiosity. I suspect it's got to do with some lookahead.

I had a look at this. I have been testing with the input a{x}, which faces the same problem. 

It's actually because of an invalid_* rule. The call stack looks like this:

...
invalid_comprehension_rule(Parser * p) (/home/lysnikolaou/repos/cpython/Parser/parser.c:15065)
genexp_rule(Parser * p) (/home/lysnikolaou/repos/cpython/Parser/parser.c:11381)
primary_raw(Parser * p) (/home/lysnikolaou/repos/cpython/Parser/parser.c:10361)
primary_rule(Parser * p) (/home/lysnikolaou/repos/cpython/Parser/parser.c:10285)
await_primary_rule(Parser * p) (/home/lysnikolaou/repos/cpython/Parser/parser.c:10240)
...

The invalid_comprehension rule acecpts an LBRACE as the starting token and only fails after it's parsed it, which means that the parser fails with three tokens in the tokens array, the NAME which is valid, the LBRACE which is parsed for the invalid_comprehension rule and the NAME thereafter, upon which the parser fails and backs out of everything. Then, we look at the last token we've parsed and that's where we're placing the caret.

Because of invalid_comprehension, we can even go as far as making the parser show a completely different error, for example:

➜  cpython git:(master) ✗ cat a.py
a{*x for x in a}
➜  cpython git:(master) ✗ ./python a.py
  File "/home/lysnikolaou/repos/cpython/a.py", line 1
    a{*x for x in a}
      ^
SyntaxError: iterable unpacking cannot be used in comprehension

Or place the caret even further:

➜  cpython git:(master) ✗ cat a.py     
a{*x + a + b + c}
➜  cpython git:(master) ✗ ./python a.py
  File "/home/lysnikolaou/repos/cpython/a.py", line 1
    a{*x + a + b + c}
                    ^
SyntaxError: invalid syntax

There's a simple fix, which is adding an alternative to the primary rule, that parses something along the lines of `primary set` and then call RAISE_SYNTAX_ERROR_KNOWN_LOCATION there, but that would have to come before the genexp alternative, which worries me because of the performance implications. `primary` is a left recursive rule that gets called VERY often, probably more than a few times even when parsing a single NAME.

Minimal example
>>> a{ # or
>>> a {
In 3.8, this is immediately flagged as a SyntaxError.  In 3.9 and master, a continuation prompt is issued.  This strikes me as a parsing buglet that should preferably be fixed, as it implies that something valid *could* follow '{', thus misleading beginners.  On the other hand, after scanning my keyboard, '{' seems unique in being a legal symbol, unlike `, $, and ?, or combinations like +*, that can AFAIK never follow a name.  So it would need special handling.


Side note: for the same reason I dislike the { change, I like the generic 3.9 change for legal operators without a second operand. 
>>> a *
Both flag as SyntaxError, but in 3.8, the caret is under '*', falsely implying that '*' cannot follow a name, while in 3.9, it is under the whitespace following, correct implying that the * is legal and that the problem is lack of a second expression (on the same line without continuation).

New changeset 15acc4eaba8519d7d5f2acaffde65446b44dcf79 by Lysandros Nikolaou in branch 'master':
bpo-41659: Disallow curly brace directly after primary (GH-22996)
https://github.com/python/cpython/commit/15acc4eaba8519d7d5f2acaffde65446b44dcf79

New changeset c4b58cea4771afc0ddfdb857b0fb5115b9f4bc9f by Lysandros Nikolaou in branch '3.9':
[3.9] bpo-41659: Disallow curly brace directly after primary (GH-22996) (#23006)
https://github.com/python/cpython/commit/c4b58cea4771afc0ddfdb857b0fb5115b9f4bc9f