I am looking at good first issues. I saw this one. @Anton You raised this one. I think I have a solution but I'm not sure. Do I just submit a PR to review, or do you want to discuss here first?
I just changed ine 3472 from crates/reporting/src/error/parse.rs
to be EProvides::Provides(pos) | EProvides::IndentProvides(pos) => {
. I figured it should be the same error message
The last line in the error message does not have a newline however, which means the next shell prompt will be on the same line as the last line in the error. This is not ideal
Thanks @Kilian Vounckx, that approach sounds good. @Folkert de Vries do you know how we can add a newline at the end here?
is it this message specifically, or in general?
This message specifically, I suppose
EGeneratesWith::Identifier(pos)
This tag has the same issue, so I think it is at least two, so I suppose in general
but some get it right
right?
I don't know how to trigger all of them
messing up header parsing is relatively easy
make up some fancy new infix operator that does not parse, etc
Kilian Vounckx said:
EGeneratesWith::Identifier(pos)
This tag has the same issue, so I think it is at least two, so I suppose in general
Oh I meant this one EProvides::Identifier(pos)
also we have tests for the reporting of parse errors
This one EExposes::Identifier(pos)
for interface exposes
lists has the same issue again
I'll try to find a correct one
I did find another issue when looking:
interface Foo
exposes []
imports [foo]
When running roc check Foo.roc
on this file, it gives an EImports::ListEnd
error instead of an EImports::ModuleName
error.
Its error message is
── WEIRD IMPORTS ───────────────────────────────────────────────────── Foo.roc ─
I am partway through parsing a imports list, but I got stuck here:
2│ exposes []
3│ imports [foo]
^
I am expecting a comma or end of list, like
imports [Shape, Vector]
Again with no newline
After trying between five or ten which I knew how to trigger at random, all of them did not have the newline, so I think it is a general issue
I will finish the original issue about the specific error message, and I think the newlines is a new issue
do e.g. type checker reports also have this problem?
Kilian Vounckx said:
I will finish the original issue about the specific error message, and I think the newlines is a new issue
@Anton PR submitted
Folkert de Vries said:
do e.g. type checker reports also have this problem?
I'll try to find some
Folkert de Vries said:
do e.g. type checker reports also have this problem?
interface Foo
exposes []
imports []
foo : Str -> Str
foo = \x -> x + 1
The type error on this file has a newline
ok, so there is some inconsistency between parse and type error formatting, right?
I think so
@Anton I added the test
btw https://github.com/roc-lang/roc/pull/5607 may also be relevant here
that one is ready to merge, but maybe can be folded into something bigger
@Folkert de Vries I was doing some unrelated stuff and found the following related issue.
This file is saved in Foo.roc
:
interface Foo
exposes []
imports []
foo : F64
foo = 42
bar : F64
bar = 31
expect
foo != bar
When running roc check Foo.roc
, the error message has a newline at the end. However, when running roc test Foo.roc
, the error does not have the newline. The only difference is checking vs testing
Last updated: Jul 06 2025 at 12:14 UTC