Non-exhaustive match cases sometimes produce c or compiler errors.

[BrendanMesters]

I have found that non-exhaustive match statements can cause both c errors (segmentation faults in specific) and compiler errors.

These errors are very difficult to debug as the program doesn't give you any useful information as to what went wrong. I'm not sure if the fact that this code breaks is intended, but if this is the intended behaviour then better error messaging would be very much appreciated.

I'm running Ubuntu 20.04,

[daanx]

Ah that is a bug -- a non-exhaustive pattern that does not match should always result in a Koka exception. Do you have an example where this fails?

[BrendanMesters]

I had it occur at least twice in a project I'm doing for uni. I'll ask my responsible professor if I am allowed to share the code here

[BrendanMesters]

also one small addition, I've encountered these patterns irregardless of whether the omitted case would've ever been reached in the code. Once this was a compile time bug, but I also had a runtime bug due to a similar reason a while ago (not sure if I'd be able to reproduce that, in that instance the omitted code wouldn't have been executed anyways)

[BrendanMesters]

My supervisor gave me permission to share the code.

Note the code is currently quite messy, so yeah, thats a thing.

My repository now has a branch to show the place the error occurs. In the file simple-linter.kk on line 238 I now have a catch all for my match case that returns a Null type (note this is a type I personally created as a sort of 'error value'). If this line is not present then you'll get a compiler error (or at least I did).

The branch currently should produce the error. The state in which I created the branch shouldn't (it literally has one commit in which I add the error back in).

Good luck fixing this bug ;-)

[BrendanMesters]

If you need any more info feel free to send me a message :-D

[TimWhiting]

This should be fixed on the dev branch now.