Asher Mancinelli (Jan 29 2024 at 19:15): Asher Mancinelli (Jan 29 2024 at 19:15):As I've been learning the language and hitting syntax errors, it's been sorta frustrating that the default error message doesn't show me where the FE croaked, it just spits out the whole string. This was the first example where I added a better error message, but I've hit more since like this:
# Not capitalized in the nested case
Ty : [NotNested, Nested [Good, bad]]
We ran into an issue while compiling your code.
Sadly, we don't have a pretty error message for this case yet.
If you can't figure out the problem from the context below, please reach out at: https://roc.zulipchat.com/
Unexpected parse failure when parsing this formatting:
"app \"bad\"\n packages {\n cli: \"https://github.com/roc-lang/basic-cli/releases/download/0.8.1/x8URkvfyi9I0QhmVG98roKBUs_AZRkLFwFJVJ3942YA.tar.br\",\n }\n imports [\n cli.Stdout,\n ]\n provides [main] to cli\n\nTy : [NotNested, Nested [Good, bad]]\n\nmain =\n Stdout.line \"working\"\n"
Parse error was:
Expr(Type(TTagUnion(End(@245), @233), @232), @226)
Would anyone mind if I added a default parser error reporter to point to the source location where things went wrong, or are those error enums purposefully not handled as a way to keep TODO items around (since I assume they will eventually be handled individually like other parsing errors)?
Anton (Jan 29 2024 at 19:20):@Joshua Warner
Brendan Hansknecht (Jan 29 2024 at 19:24):I think a default error along with part of the message noting that it is a default message would be good. That way a user can log a bug if they hit it. So we can better track where we are missing a good error message (which I am sure is a lot of places)
Joshua Warner (Jan 30 2024 at 00:55):Yeah, pointing to the right spot in code should definitely happen, even if we don't have a proper error message for that case!
Last updated: Jul 05 2025 at 12:14 UTC