Capturing an untyped number can break type inference

[bhansconnect]

Compiling this will create invalid llvm ir:

app "helloWorld"
    packages { pf: "https://github.com/roc-lang/basic-cli/releases/download/0.7.1/Icc3xJoIixF3hCcfXrDwLCu4wQHtNdPyoJkEbkgIElA.tar.br" }
    imports [pf.Stdout, pf.Task]
    provides [main] to pf

main =
    a = 7

    {} <- Stdout.line "Hello, World!" |> Task.await

    b = takesF32 a

    Stdout.line "\(Num.toStr b)"

takesF32 : F32 -> F32
takesF32 = \x -> x

[bhansconnect]

Just realized, this is probably a bug in type inference and before code gen.

It is calling takesF32 while passing in an I64: @"#UserApp_takesF32_f03bf86f79d121cbfd774dec4a65912e99f5f17c33852bbc45e81916e62b53b"(i64 %a)

[ayazhafiz]

Probably worth checking the ir

[bhansconnect]

Probably is at the typechecking/mono ir level:

IR PROBLEMS FOUND:
── SYMBOL LAYOUT DOESN'T MATCH ITS USE ─────────────────────────────────────────

in 3 : ({}, I64) -> [C Str {}, C [C I32, C {}]] ((niche {I64}))

0│> procedure `#UserApp.3` (`#UserApp.9`, `#UserApp.a`):
1│      let `#UserApp.b` : Float32 = CallByName `#UserApp.takesF32` `#UserApp.a`;
2│      let `#UserApp.12` : Str = CallByName `Num.toStr` `#UserApp.b`;

#UserApp.a defined here with layout I64

0│  procedure `#UserApp.3` (`#UserApp.9`, `#UserApp.a`):
1│>     let `#UserApp.b` : Float32 = CallByName `#UserApp.takesF32` `#UserApp.a`;
2│      let `#UserApp.12` : Str = CallByName `Num.toStr` `#UserApp.b`;

#UserApp.a used as a call argument here with layout Float32
Call parameter type does not match function signature!