gh-123969: refactor _PyErr_RaiseSyntaxError and _PyErr_EmitSyntaxWarning out of compiler

[iritkatriel]

These were local to the compiler, but after the splitting it would be good to be able to use them without needing to pass in a compiler struct (which is only used for the filename).

Fixes #123969.

• Issue: Add _PyErr_RaiseSyntaxError and _PyErr_EmitSyntaxWarning #123969

[JelleZijlstra]

This change by itself feels unnecessary, but I'm guessing you'll use these functions in more places in the future. Would it make sense to change some of those other places in this PR so you can know whether the API will work for all cases.

[serhiy-storchaka]

LGTM.

[vstinner]

You still do the +1 here, so at the end, it's +2 which is wrong, no?

[iritkatriel]

This change by itself feels unnecessary, but I'm guessing you'll use these functions in more places in the future. Would it make sense to change some of those other places in this PR so you can know whether the API will work for all cases.

I want to use it in order to raise the assert(tuple) warning from ast_opt (and move the assert optimization there). It felt like putting it in the PR would lump together two different things, but I could do it that way.

[vstinner]

I prefer a separated PR just for these two PyErr functions.

[vstinner]

LGTM.

Is the +1 on col_offset needed because compile.c counts starting at 0 and the displayed error starts counting at 1?

[iritkatriel]

LGTM.

Is the +1 on col_offset needed because compile.c counts starting at 0 and the displayed error starts counting at 1?

SyntaxError is defined to start at 1: https://docs.python.org/3/library/exceptions.html#SyntaxError

[iritkatriel]

LGTM.
Is the +1 on col_offset needed because compile.c counts starting at 0 and the displayed error starts counting at 1?

SyntaxError is defined to start at 1: https://docs.python.org/3/library/exceptions.html#SyntaxError

The location comes from the AST, where it starts at 0.