Expect with nested oneOf causes compiler panic

[j-maas]

It seems that there is some weird interaction with nested oneOfs and expectations. When I run the code below, I get this compiler error:

jojo@Windows-PC:~/code/feed-reader$ roc test backend/test.roc
[... some warnings about unnecessary definitions ...]
thread 'main' panicked at 'Error in alias analysis: duplicate function name FuncName("\x14\x00\x00\x00\x0b\x00\x00\x00\x02hE\x88u\xeaN\x8f") in module', crates/compiler/gen_llvm/src/llvm/build.rs:5761:19
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This might be related to https://github.com/lukewilliamboswell/roc-parser/issues/11, but I can't tell from that issue alone. I posted this here, because I'm not sure if this is a compiler bug or if something in this package is causing it (though I'm guessing it might be a compiler bug).

This is minimal reproduction code. You should be able to put it in a file in the root of this repository and run it with roc test to see the error.

app "hello-world"
    packages {
        pf: "https://github.com/roc-lang/basic-cli/releases/download/0.8.1/x8URkvfyi9I0QhmVG98roKBUs_AZRkLFwFJVJ3942YA.tar.br",
        parser: "./package/main.roc",
    }
    imports [
        pf.Stdout,
        pf.Task.{ Task },
        parser.Core.{ Parser, oneOf },
        parser.String.{ Utf8 },
    ]
    provides [main] to pf

Node : [
    Element (List Node),
]

pElement : Parser Utf8 _
pElement =
    # Removing one of the `oneOf`s solves the panic
    oneOf [
        oneOf [
            pElement,
        ],
    ]

expect
    # Removing this access solves the panic
    _temp = pElement
    Bool.true

main : Task {} I32
main =
    _temp =
        # This access does not cause the panic
        pElement
    Stdout.line "Testing"

[j-maas]

In my real code, using alt instead of oneOf makes it compile: https://github.com/j-maas/roc-xml-parser/commit/aba23d22376ddf997be94b8e23c584f889b8341f

[lukewilliamboswell]

@j-maas thank you for posting this. The Error in alias analysis part tells me this is probably a lambda set issue, possibly related to recursive types. I think it would be helpful to also post this to the roc repository, or at least an issue over there that links to this.

It's not something I think I will be able to fix, but I'm glad you have shared a work around.

😃

[j-maas]

Thanks for the feedback, will do that when I find the time. 👍