Compiler panic when trying to alias a function type from the Record Builder example

[jming422]

I'm new to Roc and was trying to learn about record builders from the docs example, and I ran into some unexpected things.

First and most minor, Str.split doesn't exist, seems to have been renamed to Str.splitOn -- easy enough change to discover and make on my own. After that change, the full code as written in the example works 👍🏼

But then I saw that the type (Str -> Result a ParserErr) was repeated in both parseWith and buildSegmentParser, and I wanted to try giving that type a shorter alias, both to test my knowledge of how to do type aliases and also to help me more easily read those functions' signatures.

So I changed this line:

parseWith : (Str -> Result a ParserErr) -> ParserGroup a

To this:

ParseFn a : Str -> Result a ParserErr

parseWith : ParseFn a -> ParserGroup a

After this change, roc check reported no issues, so I thought I was good to go, but then when I ran roc test I got strange behavior:

➜  roc check recordbuilder.roc
roc: /lib64/libtinfo.so.6: no version information available (required by roc)
0 errors and 0 warnings found in 19 ms
➜  time roc test recordbuilder.roc
roc: /lib64/libtinfo.so.6: no version information available (required by roc)
thread '<unnamed>' panicked at crates/compiler/mono/src/layout.rs:3778:26:
invalid content in tag union variable: Structure(Func(Slice<roc_types::subs::Variable> { start: 2506, length: 1 }, 3934, 3936, 3937))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
^C
roc test recordbuilder.roc  281.47s user 0.04s system 99% cpu 4:44.14 total

The compiler panicked, and then it seems like it got stuck, because it spun up my CPU fans and sat there for longer than I was willing to wait before hitting Ctrl-C.

I'm on Linux x86_64, latest roc version as of this writing roc nightly pre-release, built from commit d72da8e on Fr 29 Nov 2024 09:11:57 UTC

Here's the full code:

module [
    ParserGroup,
    ParserErr,
    parseWith,
    chainParsers,
    buildSegmentParser,
]

# https://www.roc-lang.org/examples/RecordBuilder/README.html

ParserErr : [InvalidNumStr, OutOfSegments]

ParserGroup a := List Str -> Result (a, List Str) ParserErr

ParseFn a : Str -> Result a ParserErr

parseWith : ParseFn a -> ParserGroup a
parseWith = \parser ->
    @ParserGroup \segments ->
        when segments is
            [] -> Err OutOfSegments
            [first, .. as rest] ->
                parsed = parser? first
                Ok (parsed, rest)

chainParsers : ParserGroup a, ParserGroup b, (a, b -> c) -> ParserGroup c
chainParsers = \@ParserGroup first, @ParserGroup second, combiner ->
    @ParserGroup \segments ->
        (a, afterFirst) = first? segments
        (b, afterSecond) = second? afterFirst

        Ok (combiner a b, afterSecond)

buildSegmentParser : ParserGroup a -> (Str -> Result a ParserErr)
buildSegmentParser = \@ParserGroup parserGroup ->
    \text ->
        segments = Str.splitOn text "-"
        (date, _remaining) = parserGroup? segments

        Ok date

expect
    dateParser =
        { chainParsers <-
            month: parseWith Ok,
            day: parseWith Str.toU64,
            year: parseWith Str.toU64,
        }
        |> buildSegmentParser

    date = dateParser "Mar-10-2015"

    date == Ok { month: "Mar", day: 10, year: 2015 }

It's totally possible that I did something wrong here, please let me know if so! But I thought either way the compiler is likely not supposed to panic so I might as well file the issue

[lukewilliamboswell]

The first thing I noticed is that here parseWith : ParseFn a -> ParserGroup a you are making a type alias but using a lowercase letter. In roc Types are PascalCase, and identifiers like functions and variable are camelCase with a lower-case starting letter. nvm this was a function type annotation

Thank you for reporting

[jming422]

Sure thing, let me know if there's anything else I can do to help! I have quite a bit more experience with Rust than with Roc, but I haven't worked on a compiler before, so when I poked around at the reported source file I was too overwhelmed to come out with any useful insight for now.