The "--errors N --compile-only" options producing incorrect errors and even segfault

[inferrna]

lobster --errors 10 --compile-only test.lobster

1. Local variables "shadowing" other local variables
2. Segmentation fault (achieved by recursion)

test.lobster.gz

[aardappel]

Certainly any more errors than 1 is not tested much, and this is something difficult to get right, most compilers produce non-sense errors after the first in many conditions. To get this right every error needs to code to try and correct the specific error, and this compiler doesn't have any.

It should never crash though, I can look into that.

[aardappel]

Yeah, not sure if this can generally be solved. Any error aborts the current code. That first error started parsing a function body (one passed to gl.color), then aborted, leaving a half initialized function on the stack of functions, that later code then refers to and crashes.

To avoid these kind of crashes, around ANY error (there are >100 of them) we'd need to ensure that a) compiler state is in a consistent state (i.e. no multi-step initialization like here), and it comes with custom correction/unwinding code (like in this case, removing the half-finished function). That is an an enormous amount of work, lots of brittle code, code that is hard to test it is even correct (need to test every error in.. every context?)

That, or remove the --errors option accepting it cannot work reliably.

Or, have a solid multi-platform crash handler that in the case of --errors >= 2 is able to simply abort giving more errors. Which sounds bad too.