Quite a few unhandled syntax errors have accumulated over the years. It's easy to forget to handle these in reporting because we have wildcard match branches that just call todo!():
thread 'main' panicked at crates/reporting/src/error/parse.rs:681:14:
not yet implemented: unhandled parse error: Return(ReturnValue(Start(@11579), @11579), @11572)
That experience is pretty bad when you hit one. You don't know which file the error is in, and you only get byte offsets instead of a line and column.
We should handle all of those, but in the meantime, this PR removes all wildcard pattern matching on parser errors to prevent more cases from accumulating.
Furthermore, it improves the experience for the existing unhandled cases by printing a more intentional report that includes the file and region:
── UNHANDLED PARSE ERROR in src/Pg/BasicCliClient.roc ──────────────────────────
I got stuck while parsing this:
437│ return : a -> Task [Done a] *
^
Here's the internal parse problem:
Return(ReturnValue(Start(@11579), @11579), @11572)
Unfortunately, I'm not able to provide a more insightful error message
for this syntax problem yet. This is considered a bug in the compiler.
Note: If you'd like to contribute to Roc, this would be a good first issue!
Let me know what you think of that note. I thought it was a nice opportunity to encourage contributions, but I'm happy it to drop it if we don't want the compiler to do that.
Quite a few unhandled syntax errors have accumulated over the years. It's easy to forget to handle these in reporting because we have wildcard
match
branches that just calltodo!()
:That experience is pretty bad when you hit one. You don't know which file the error is in, and you only get byte offsets instead of a line and column.
We should handle all of those, but in the meantime, this PR removes all wildcard pattern matching on parser errors to prevent more cases from accumulating.
Furthermore, it improves the experience for the existing unhandled cases by printing a more intentional report that includes the file and region:
Let me know what you think of that note. I thought it was a nice opportunity to encourage contributions, but I'm happy it to drop it if we don't want the compiler to do that.