This isn't a serious blocker. I'm just writing to report that I've run into it and to flag it as a possible bug. If confirmed as a bug by the maintainers' team, I'd be happy to file a GitHub issue, if that'd be the preferred course of action,
Roc online REPL:
» f = \n, p -> Num.pow Num.e (Num.div (Num.log n) p)
panicked at 'Invalid return layout for NumLogUnchecked: InLayout(DEC)', crates/compiler/gen_wasm/src/low_level.rs:178:13
» f = \n, p -> Num.pow Num.e (Num.div (Num.logChecked n |> Result.withDefault 0.0) p)
panicked at 'Invalid return layout for NumLogUnchecked: InLayout(DEC)', crates/compiler/gen_wasm/src/low_level.rs:178:13
Locally (not in REPL, but via roc test
):
thread 'main' panicked at 'internal error: entered unreachable code: Unrecognized dec unary operation: NumLogUnchecked', crates/compiler/gen_llvm/src/llvm/lowlevel.rs:2209:13
Thanks!
Ah, we are missing some wiring in the wasm backend to newer builtins. Yeah, definitely a bug
Hi @Brendan Hansknecht, thanks for looking into this!
Given that this is also reproducible locally, in a non-REPL context, wouldn't it be considered a more general than just WASM? I've run into a similar bug when attempting other Num.log
-based calculations.
This time around I've accompanied my reproducible example with output from the online REPL, because in my previous reports (unrelated to this thread), I wasn't really sure how much was due to my local environment.
Ah yeah error is hit in llvm backend too. Yeah probably all backend would hit it.
I guess that means we have it wired up for floats but not dec
I guess that means we have it wired up for floats but not dec
Yes, the error messages suggest something like that might've happened indeed :thumbs_up:
Last updated: Jul 06 2025 at 12:14 UTC