You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# repro.pyimportlibcstsource="def f(*):\n pass\n"libcst.parse_module(source)
compile(source, "", "exec") # for comparison
$ python repro.py
Traceback (most recent call last):
libcst.parse_module("def f(*):\n pass\n")
...
libcst._exceptions.ParserSyntaxError: Syntax Error @ 2:5.
parser error: error at 1:8: expected one of ,, NAME
pass
^
# and if we comment out the `parse_module()` call, we see Python gives us:
Traceback (most recent call last):
compile(source, "", "exec")
...
deff(*):
^SyntaxError: named arguments must follow bare *
The error message we get from libcst points to 1:8, i.e. the close-paren of the function definition, but the exception metadata instead points to the end of the function body (for def f(*): ... it points to the start of the def). Additionally, we see expected one of ,, NAME, which suggests that the message is constructed from three alternatives of which two have an empty string representation.
I've included the error raised by Python 3.10 for comparison; it points directly to the * and has a presumably-hand-written message explaining what's going on. Unclear how much of that is worth adopting or copying over, but testing that the location of syntax errors is compatible might be worthwhile?
The text was updated successfully, but these errors were encountered:
I completely agree the parser error messages are often downright misleading as opposed to helpful. It would be great to improve them, but currently the parser generator library we use make it difficult to emit high-quality error messages.
See kevinmehall/rust-peg#276 and kevinmehall/rust-peg#289 for improving that situation.
Passing this on from HypothesisWorks/hypothesis#3759:
The error message we get from
libcst
points to1:8
, i.e. the close-paren of the function definition, but the exception metadata instead points to the end of the function body (fordef f(*): ...
it points to the start of the def). Additionally, we seeexpected one of ,, NAME
, which suggests that the message is constructed from three alternatives of which two have an empty string representation.I've included the error raised by Python 3.10 for comparison; it points directly to the
*
and has a presumably-hand-written message explaining what's going on. Unclear how much of that is worth adopting or copying over, but testing that the location of syntax errors is compatible might be worthwhile?The text was updated successfully, but these errors were encountered: