-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] Not handling all cases during pattern-matching in lambdas #1436
Comments
This is reporting a case where we actually aren't handling all possible cases in the compiler. Do you have some example code that triggered this? |
Sure, let me whip up some code to reproduce it. A moment. |
Crashes the carp interpreter with version 0.5.5
Not sure if it's possible to reduce this example even further |
Thanks a ton, @AZMCode! I'll take a look and see if I can get a fix in the next day or two. |
Thank you for taking the time. |
After a long time not using the language, I came back to it for funsies, stumbled upon this bug again, and decided to reduce the code further. Here's an updated example that triggers the exact same bug:
|
I don't know if this code is valid at all, but it surely shouldn't crash the interpreter/compiler |
This short repo case is great to have, thank you @AZMCode! I am hoping to spend some more time on Carp again soon and can try to fix this. (wound up getting busy with other things as usual, after pledging to work on this before, but it is still on my radar!) |
As of now, using a non-exhaustive pattern in a lambda returns the following error message
With zero indication of where the offending lambda is located in code, unlike other compile time error messages.
The text was updated successfully, but these errors were encountered: