Calling function that does not exist should produce clean error message that says so.
➜ roc-learn RUST_BACKTRACE=full roc repl
The rockin' roc repl
────────────────────────
Enter an expression, or :help, or :q to quit.
» List.map [StrElem "A", StrElem "b", NumElem 1, StrElem "c", NumElem -3] \elem ->
… when elem is
… NumElem num -> Num.isNegative num
… StrElem str -> Str.isCapitalized str
… # returns [Bool.true, Bool.false, Bool.false, Bool.false, Bool.true]
thread 'main' panicked at crates/compiler/gen_dev/src/generic64/aarch64.rs:1861:13:
not yet implemented: immediate subtractions with values greater than 12bits
stack backtrace:
0: 0x1018c716c - __mh_execute_header
1: 0x100d0744c - __mh_execute_header
2: 0x1018c3150 - __mh_execute_header
3: 0x1018c6f64 - __mh_execute_header
4: 0x1018c8680 - __mh_execute_header
5: 0x1018c837c - __mh_execute_header
6: 0x1018c8c84 - __mh_execute_header
7: 0x1018c8a34 - __mh_execute_header
8: 0x1018c7604 - __mh_execute_header
9: 0x1018c87f4 - __mh_execute_header
10: 0x102fa43dc - __ZN4llvm15SmallVectorBaseIyE8grow_podEPvmm
11: 0x10113c3e8 - __mh_execute_header
12: 0x1011ae3a4 - __mh_execute_header
13: 0x1011a2d5c - __mh_execute_header
14: 0x10119fc28 - __mh_execute_header
15: 0x1016161f0 - __mh_execute_header
16: 0x10161d7dc - __mh_execute_header
17: 0x100ec3774 - __mh_execute_header
18: 0x100e9f644 - __mh_execute_header
19: 0x100e9f668 - __mh_execute_header
20: 0x1018bb208 - __mh_execute_header
version
roc nightly pre-release, built from commit 33075285b72 on Wed May 22 09:12:12 UTC 2024
Thanks for reporting this @BlowaterNostr!
isCapitalized no longer exists, I'll update the tutorial.
Using Str.startsWith str "A" does not cause any problems, we should still fix this not yet implemented though.
Yeah, instead of panicing, it should tell me that function XXX does not exist
I made https://github.com/roc-lang/roc/issues/6812 for improving todo error messages.
The tutorial was changed to remove isCapitalized and there's a new issue for improving the error message, so there's nothing left to do on this issue. Marking it complete.
(Of course the todo! that caused the crash still exists, so this isn't totally completed, but we don't need an issue to track that.)
I like to have issues for todo's that users actually hit. It's really easy to forget about todo!s in the code.