Add builtins for dec and float

[FabHof]

Discussion: https://roc.zulipchat.com/#narrow/stream/383402-API-Design/topic/reading.20integers.20from.20bytes/near/418549425

I implemented it as far as I "easily" could. The two new Dec functions worked in the repl and llvm, but I have no idea if what I did is a good idea. For the F32/F64 functions, they work in the repl, but for llvm I don't know what to do exactly. I don't know how to test wasm so I just copied stuff from other implementations and hope it works.

I also don't know how/where/if to add tests for this.

I'm happy for hints in the right direction so I can finish this.

[FabHof]

I added test and comments, but I cannot get llvm to work. Ror me it would be easier to move it to roc and have only an internal f32 to/from u32

[Anton-4]

@FabHof progress update: I've put up some plausible code for NumF32ToParts and asked for help on zulip to fix it up.

[Anton-4]

Awesome @FabHof :) let us know if you need help with the rest.

[FabHof]

@bhansconnect @Anton-4 Thank you both for the help. I was fun diving into llvm, and I think I have now all abi cases covered. Not sure if I missed some helper function that would have made this easier, so I created my own.

I do not use the Target enum but look at the arguments/return type of the function, which was not as confusing to me. I hope that is fine.

[FabHof]

I don't understand why platform_switching_zig failed. https://github.com/roc-lang/roc/actions/runs/8512456445/job/23315264447?pr=6591

According to my bisect and testing, here is the commit that causes the failure:

https://github.com/roc-lang/roc/commit/546cb17fb941e92eed23acd286dc50166c507783#diff-b41bd789b14148ac97d57750d3dda3932e52d37bf5f04d387b6f34cc6add459eL665-R665

I'm a bit puzzled.

[bhansconnect]

I don't understand why platform_switching_zig failed.

Ah, this is huge....not that I like it, but actually a really useful piece of information. You are fine to ignore the test and submit. Or better, if possible, set it to use the legacy linker only.

Roc command failed with status ExitStatus(unix_wait_status(35584)):

@rtfeldman @Anton-4 I think this is the first time seeing https://github.com/roc-lang/roc/issues/6121 on a non-rust platform. Not that I have an immediate idea what is wrong from this, but the fact it is cross language rules out a lot of toolchain issues as the cause. It also gives us another example to dig into that is less complex since it is just hello world in zig.

[Anton-4]

Interesting, I can dig in a bit today or tomorrow

[FabHof]

Good to know that my bug creation skills are valuable.

I set platform_switching_zig to ignore, but now locally the tests in crates/valgrind/src/lib.rs fail for me.

[bhansconnect]

@Anton-4 any idea what is going on with the valgrind tests?

[Anton-4]

No not yet, I'm currently looking at https://github.com/roc-lang/roc/pull/6603 but I'll try to inspect the valgrind failures after that.

[Anton-4]

I could not reproduce this on my NixOS machine, so far it only happens on CI. Valgrind does work normally on the CI machine if I test it standalone on our helloWorld executable. This will require some more investigation, I'll continue on Friday...

[Anton-4]

Alright, the executables valgrind was failing on were segfaulting. I was able to run valgrind on them manually:

$ valgrind ./str_trim_start 
==885645== Memcheck, a memory error detector
==885645== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==885645== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==885645== Command: ./str_trim_start
==885645== 
==885645== 
==885645== Process terminating with default action of signal 11 (SIGSEGV)
==885645==  Bad permissions for mapped region at address 0x222060
==885645==    at 0x222060: ??? (in /home/small-ci-user/gitrepos/forks/fabhof/roc/crates/valgrind/str_trim_start)
==885645==    by 0x1D2007: ??? (in /home/small-ci-user/gitrepos/forks/fabhof/roc/crates/valgrind/str_trim_start)
==885645==    by 0x19D655: ??? (in /home/small-ci-user/gitrepos/forks/fabhof/roc/crates/valgrind/str_trim_start)
==885645==    by 0x19B3C2: ??? (in /home/small-ci-user/gitrepos/forks/fabhof/roc/crates/valgrind/str_trim_start)
==885645==    by 0x1F199A: ??? (in /home/small-ci-user/gitrepos/forks/fabhof/roc/crates/valgrind/str_trim_start)
==885645==    by 0x1E2650: ??? (in /home/small-ci-user/gitrepos/forks/fabhof/roc/crates/valgrind/str_trim_start)
==885645==    by 0x1CF748: ??? (in /home/small-ci-user/gitrepos/forks/fabhof/roc/crates/valgrind/str_trim_start)
==885645==    by 0x19C9AC: ??? (in /home/small-ci-user/gitrepos/forks/fabhof/roc/crates/valgrind/str_trim_start)
==885645==    by 0x4893A6F: ??? (in /nix/store/9y8pmvk8gdwwznmkzxa6pwyah52xy3nk-glibc-2.38-27/lib/libc.so.6)
==885645==    by 0x22201F: ??? (in /home/small-ci-user/gitrepos/forks/fabhof/roc/crates/valgrind/str_trim_start)
==885645==    by 0x19CDC0: ??? (in /home/small-ci-user/gitrepos/forks/fabhof/roc/crates/valgrind/str_trim_start)
==885645==    by 0x19AD99: ??? (in /home/small-ci-user/gitrepos/forks/fabhof/roc/crates/valgrind/str_trim_start)
==885645== 
==885645== HEAP SUMMARY:
==885645==     in use at exit: 0 bytes in 0 blocks
==885645==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==885645== 
==885645== All heap blocks were freed -- no leaks are possible
==885645== 
==885645== For lists of detected and suppressed errors, rerun with: -s
==885645== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

No segfault happens with the legacy linker:

$ valgrind ./str_trim_start 
==885673== Memcheck, a memory error detector
==885673== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==885673== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==885673== Command: ./str_trim_start
==885673== 
Bruntime: 8.101ms
==885673== 
==885673== HEAP SUMMARY:
==885673==     in use at exit: 0 bytes in 0 blocks
==885673==   total heap usage: 1 allocs, 1 frees, 72 bytes allocated
==885673== 
==885673== All heap blocks were freed -- no leaks are possible
==885673== 
==885673== For lists of detected and suppressed errors, rerun with: -s
==885673== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

This was the tested program:

app "test"
    packages { pf: "zig-platform/main.roc" }
    imports []
    provides [main] to pf

main =
    str = "    a" |> Str.reserve 30
    out = str |> Str.trimStart

    if out == "" then "A" else "B"

This is the executable: ~~str_trim_start.tar.gz~~

[Anton-4]

~~I can run the CI generated executable on my NixOS machine and there it does not segfault, nor does valgrind see any issues with it.~~

[Anton-4]

I uploaded the wrong executable, one sec...

[Anton-4]

This is the correct one (generated on the small-ci machine): str_trim_start.tar.gz

This one does segfault when I run it on NixOS and it also generates the exact same valgrind output.

[Anton-4]

Looking at the strings diff; on my NixOS machine it's targeting a generic x86_64 CPU, and on CI intel haswell. I'm going to try forcing generic x86_64 (if that's the architecture), because that difference has caused hard to reproduce behavior in the past as well.

[Anton-4]

:tada:

[Anton-4]

Thanks @FabHof and @bhansconnect :heart: This was quite the journey :smile: