The following is a reduced case of a compiler crash and hang I encountered
app "a"
packages { pf: "https://github.com/roc-lang/basic-cli/releases/download/0.7.0/bkGby8jb0tmZYsy2hg1E_B2QrCgcSTxdUlHtETwm5m4.tar.br" }
imports [pf.Stderr, pf.Task.{ Task }]
provides [main] to pf
main =
Task.ok {}
|> Task.onErr \e ->
dbg e
Stderr.line ""
Error:
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', crates/compiler/mono/src/ir.rs:6152:56
which command? does it hang with roc build
and roc check
?
Sorry, forgot to mention, it fails with roc build
but passes roc check
thread '<unnamed>' panicked at 'unspecialized lambda sets left over during resolution: LambdaSet([] + (<2171>FlexAble(*, [`Inspect.Inspect`]):`Inspect.toInspector`:2), ^<2174>), UlsOfVar(VecMap { keys: [2171], values: [VecSet { elements: [2170, 2173] }] })', crates/compiler/mono/src/layout.rs:2074:17
cc @Ayaz Hafiz in case he has any immediate ideas or comments around the issue in general. The error type here should be I32
due to the type of main
in the platform.
We seem to be getting different errors :thinking:
(updated the initial message with the error)
John I'm assuming you're running Roc via a release of the compiler? Brendan hit an earlier assertion in a debug version of the compiler, but the issue is the same
I'm not 100% why this is happening. My guess is it's because the type wanted by the platform might not be visible at the time the app is specialized. If you explicitly annotate main
here it should resolve that. I think we've discussed making that mandatory anyway.
Last updated: Jul 05 2025 at 12:14 UTC