Improve compiler error and warning experience

[perlun]

Moved to GitLab

Please continue to the new version of this issue here: https://gitlab.perlang.org/perlang/perlang/-/issues/218. The GitHub page you are currently reading will not contain the latest information on this issue.

---

Let's face it. The way we currently emit compiler warnings and errors is rather unsatisfactory. For example, a program like this (before #69 is fully implemented and hence, binary literals do not yet work):

var v = 0b00101010;

...yields the following output:

[line 1] Error at 'b00101010': Expect ';' after variable declaration.

While this works, it's not at all as pretty as it could be:

• The exact (or at least approximate) column number could be included.
• For some errors, the line number isn't even included. (I think this happens on runtime exceptions in "native" .NET code being called - this is in fact fine, we should be using a separate error handler for displaying runtime errors.)

What we should be aiming for

Contrast the above with the following Rust program. The program is invalid since there is no 0y-prefix supported by the language.

fn main() {
    let i: i32 = 0y1000000000000000000000000000000;
}

Here's the error message:

There are lots of nice things going on here:

1. The exact line and colum is displayed, making it easy for the programmer to understand what's causing this.
2. The source line is even included and printed out.
3. The failing token is underlined to make it "almost impossible" to misunderstand what part of the line caused the issue.

We could pretty much aim for a 1-to-1 experience, similar to the above. For scanning-related bugs, this should be doable, but the further down the processing (the farther away from the source code reading you get), the more complex it will likely be to provide this kind of end-user experience.

It probably makes sense to aim for the "low-hanging fruit" first, i.e. make something reasonably close to the above for scanning-style errors. Then move further down the stack:

• name resolving errors
• type resolving errors
• immutability errors
• etc

Something like this. There's no rush; I'm more interested in us providing something great than this happening too quickly, with inferior end-user quality.