Tested in 3.9.0 and master (127dde5916):

$ cat test.py
eval(
    """[file for str(file) in []
]
"""
)

$ ./python test.py
python: Parser/pegen.c:149: byte_offset_to_character_offset: Assertion `col_offset >= 0 && (unsigned long)col_offset <= strlen(str)' failed.
Fatal Python error: Aborted

Current thread 0x00007f6454cfe280 (most recent call first):
  File "/home/mdk/clones/python/cpython/test.py", line 1 in <module>
Aborted (core dumped)

(Adding Guido and Pablo to nosy as, IIRC, you're interested in parser things :))

Reproducer as a single line:

compile("[file for str(file) in []\n]", "string", "exec")

According to git bisect it come from 01ece63d42b830df106948db0aefa6c1ba24416a, thanks Victor for adding Lysandros, you had a good feeling :)

Thanks for letting us know, Julien! I've identified the bug and where it comes from and I'll probably work on it tomorrow.

New changeset e5fe509054183bed9aef42c92da8407d339e8af8 by Lysandros Nikolaou in branch 'master':
bpo-42827: Fix crash on SyntaxError in multiline expressions (GH-24140)
https://github.com/python/cpython/commit/e5fe509054183bed9aef42c92da8407d339e8af8

This is now fixed.

On Windows, Victor's one liner failed on repository debug builds with Windows' process error popup.  I have seen this mysterious failure at least once when testing IDLE Shell running on the repository build.   After the patch, my debug build gives the correct message,
  SyntaxError: cannot assign to function call
and correctly points to the 's' of 'str' on the first line.  Ditto when run from IDLE's Shell or editor.  Thank you for the fix.

Installed Python 3.10.0a4, Jan 4, gives the correct message  but confusingly points at the final ']' on a line by itself.  The latter should be fixed in the next release.

In order to test code.InteractiveCompiler (used by IDLE) and codeop._maybe_compile (which IC calls), which calls compile() 3 times with mode 'single', I entered the example as 2 or 3 lines in Shell.
>>> [file for str(file) in []  # Error highlight on 's'.
 ]
SyntaxError: cannot assign to function call

Breaking the expression elsewhere, including before 'str', gives the same message and highlighted 's'.

I did not test before recompiling but it is certainly correct now.