Why can't we use the KNOWN_LOCATION variant here?

Why can't we use the normal RAISE_SYNTAX_ERROR_KNOWN_LOCATION here?

The reason is because I want to point to the end of the expression, not to the begging of it (because that's where the comma should be).

(I deleted my previous comment because I forgot that this was the real reason)

Correct. It's good to go then.

(Now you've gotten me really interested though.)

@lysnikolaou 🤫🤫🤫🤫🤫

>>> f(a, b, x for x in range(10))
  File "<stdin>", line 1
    f(a, b, x for x in range(10))
            ^^^^^^^^^^^^^^^^^^^^
SyntaxError: Generator expression must be parenthesized

>>> blech bluch
  File "<stdin>", line 1
    blech bluch
          ^^^^^
SyntaxError: invalid syntax

>>> {1:2, 3: *3434, 3:4}
  File "<stdin>", line 1
    {1:2, 3: *3434, 3:4}
             ^^^^^
SyntaxError: cannot use a starred expression in a dictionary value

@lysnikolaou Actually, I may need help with this if we want to get it to beta freeze. Do you want to give me a hand?

Oh wow! Yup, count me in! How should we go about it?

Checkout my prototype: https://github.com/pablogsal/cpython/tree/tokenizer_better_errors

This basically adds a "end column offset" to syntax errors and threads it down everywhere.

The moderate bigger task is to make the parser/grammar to populate that accordingly. Now I am doing this hack:

https://github.com/pablogsal/cpython/blob/tokenizer_better_errors/Parser/pegen.c#L426

as a way to populate that.

Basically what's left is to productionalise this. There are several things to do:

• The hack doesn't work always (check one of the new dict errors like {1:2, 3, 3:3}.
• Devise a better way to make the parser inject this automatically and maybe a new macro so you can mark the beginning and the end passing two tokens instead of 1.
• Tests