Hi, while working on this issue: 6208 I bumped into some weird unification error and don't know what to try next.
I found the ROC_PRINT_MISMATCHES
debug flag and the mismatch is Num.FloatingPoint
.
Here are my changes so far: https://github.com/lindskogen/roc/commit/aa194419ac6160caf40710cee76e67a820c82430
ROC_PRINT_MISMATCHES=1 cargo run dev examples/cli/echo.roc
Finished dev [unoptimized + debuginfo] target(s) in 0.27s
Running `target/debug/roc dev examples/cli/echo.roc`
Mismatch in crates/compiler/unify/src/unify.rs Line 978 Column 17
`Num.FloatingPoint`
An internal compiler expectation was broken.
This is definitely a compiler bug.
Please file an issue here: https://github.com/roc-lang/roc/issues/new/choose
thread '<unnamed>' panicked at 'ambient functions don't unify', /Users/johan/Projects/roc/crates/compiler/unify/src/unify.rs:201:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Hmm, probably some code says that those only support float and adding Dec as an option is confusing it.
I know I've seen this before, but it's been so long
Found a couple of issues in my code, where I didn't define DEC_SQRT & DEC_POW, but the issue stays the same :oh_no: https://github.com/roc-lang/roc/compare/main...lindskogen:roc:implement-sqrt-pow-for-dec
I'll try to take a look at this tomorrow. That said, @Ayaz Hafiz any immediate ideas?
Possibly the call to Inspect.toStr v? That seems like maybe a type mismatch?
Does it work if you do Num.toStr v in your sample app instead
Inspect.toStr
should have the same type (once made concrete) as Num.toStr
, but autoderive or something could totally be bugged.
When I try Num.toStr instead I get this:
Mismatch in crates/compiler/unify/src/unify.rs Line 1088 Column 17
Cannot unify structure TagUnion(UnionLabels { length: 2, labels_start: 10, values_start: 243, _marker: PhantomData<roc_module::ident::TagName> }, Any(125)) with opaque `Num.Num`
Last updated: Jul 06 2025 at 12:14 UTC