Error report enhancement

[SebastianMestre]

When compared with pretty much any other statically checked language, Jasper's errors are straight-up laughable. I intend to change that. To improve the situation, I'm building a bunch of utilities that will help generate nicer errors. In particular I thought that printing the line where the error happened, with a caret pointing at the exact token would be a great addition.

Supporting this change, I extended ErrorReport to store multiple lines of error messages per node.

I just stuffed all this in parser.cpp for now, but it probably deserves its own file.

---

A little example:

fn f(x, y) {
	print(10;
};

-- Failed to parse function declaration
---- Failed to parse statement
------ Failed to parse expression
-------- Failed to parse argument list
---------- Unexpected token: expected a terminator or delimiter but found ';' instead
           2 |     print(10;
                           ^ unexpected token is here

---

strings := array {
	"HELLO, MY NAME IS JASPER";
	"I WOULD LIKE TO BE YOUR FRIEND";
	"AW YISSSSSS" ];

-- Failed to parse declaration
---- Failed to parse expression
------ Failed to parse array literal
-------- Mismatched braces: expected a terminator or delimiter but found ']' instead
         4 |     "AW YISSSSSS" ];
                               ^ unexpected token is here
         1 | strings := array {
                              ^ opening brace is here

[lushoBarlett]

Another thing I'd like to point out is: isn't every error message a perfect diagonal line? What I mean is there are no instances where a CST node has errors in multiple of its children, we just bail as soon as we encounter one.

If this is not expected to change, maybe we can ditch the tabulations increase in each successive child.

Another, perhaps interesting and useful thing, may be to write the line number of every error. I am not sure about this one, but at least I can throw it out there.

[SebastianMestre]

Another thing I'd like to point out is: isn't every error message a perfect diagonal line? What I mean is there are no instances where a CST node has errors in multiple of its children, we just bail as soon as we encounter one.

If this is not expected to change, maybe we can ditch the tabulations increase in each successive child.

Yeah that's a fair point. Parsing errors are usually simple enough that you don't need tree-shaped errors.

I designed ErrorReport with the possibility of a backtracking or error-correcting parser in mind (where tree-shaped errors make a lot of sense), but that's so hypothetical that it's not worth making the current error messages more complicated and uglier than they need to be.

EDIT: On second thought, I kinda like how the indentation looks, but I think there are way too many levels that don't provide valuable information. Rather than removing the indentation, we should try to nest errors less deeply.

Another, perhaps interesting and useful thing, may be to write the line number of every error. I am not sure about this one, but at least I can throw it out there.

Yeah I totally agree (hence make_located_error and friends, which print both line and column), it's just a bit tedious to go through and write the code that does the right thing for every error.

Keep the ideas coming!

[SebastianMestre]

😎 😎 😎 😎 😎

-- While scanning top level declaration '__invoke'
---- At 13:8: accessed undeclared identifier 'acrilico'
     13 |     print(acrilico(3, 9));
        |           ^ 

[lushoBarlett]

We can, in the future, add colors to the output, presuming that all output goes to a terminal that accepts said color codes. Copying the error style of, say, gcc. May not be worth the effort tho.