We should have better error messages when a (non function call) expression appears in a statement position.
hugomg opened this issue · comments
Currently, if a (non function call) expression appears in statement position, the compiler generates errors like AssignAssign (expected = after variable) and EndFunc (expected end to close function body). Would it be possible to produce a more specific error message instead?
Tough one. I think this is the kind of error that I got in this situation for all languages I've ever used...
An alternative would be to try to actually parse the expression, then, if successful, produce an error (if that's a common enough error pattern). Haven't given 2 seconds of thought about possible ambiguities arising from this, though.
That second approach is kind of what the parser already does. The last rule in the statements production parses a (suffixed) expression and checks it if it is a function call with the exp_is_call capture/predicate.
It should be possible to get this better error message if we tie the error message to the result of that predicate. If lpeglabel added support for throwing labels from captures that would be a piece of cake but without that there are workarounds involving lookaheads like &suffixed_exp ( (suffixed_exp => exp_is_call) / %{ExpressionStatementError} ).
I think the biggest challenge here is actually the suffixed_exp part, which we would need to change into a more general rule that can parse every expression (exp) or at least a prefix of any expression (zero or more unop followed by a suffixed_exp). I haven't tested if this works out without introducing conflicts or ambiguities though.