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
I just fixed two specific cases, namely when my and sub are followed by a non-identifier. Instead of backtracking and trying other rules (usually statement:expr, which is very general), the parser should just give up directly with a <.panic> call.
This issue can be closed when the parser has been combed for other opportunities like this, and <.panic> calls installed. As much as possible, each such <.panic> should be accompanied by a test in t/syntax/errors.t.
The text was updated successfully, but these errors were encountered:
This issue now basically means "have decent compiler error messages", which I still want, but...
...one aspect of that is to think about "secondary source locations". That is, when a call turns out to be impossible, also link to (and show file/line information for) the function(s) whose parameters that call's arguments don't match up with.
I just fixed two specific cases, namely when
my
andsub
are followed by a non-identifier. Instead of backtracking and trying other rules (usuallystatement:expr
, which is very general), the parser should just give up directly with a<.panic>
call.See these two commits for inspiration on how to do this.
This issue can be closed when the parser has been combed for other opportunities like this, and
<.panic>
calls installed. As much as possible, each such<.panic>
should be accompanied by a test int/syntax/errors.t
.The text was updated successfully, but these errors were encountered: