Jasper Woudenberg (Mar 29 2024 at 13:24): Jasper Woudenberg (Mar 29 2024 at 13:24):I'm working on a Roc project for continuous integration and running into an 'alias analysis' error:
Project code is here
When I run roc test package/main.roc I get three warnings (that I don't think I can do anything about), but no compilation errors. Same when I run roc check package/main.roc. When I run roc run package/main.roc I get the following error:
thread 'main' panicked at 'Error in alias analysis: error in module ModName("UserApp"), function definition FuncName("\x12\x00\x00\x003\x00\x00\x00;A\xd5\xcd\xbf \x7fy"), definition of value binding ValueId(9): could not find func in module ModName("UserApp") with name FuncName("1\x00\x00\x00D\x00\x00\x00\xc4Q\x0e\xe3\xcb\xf0l\x0c")', crates/compiler/gen_llvm/src/llvm/build.rs:5779:19
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I've isolated the problem to this line. When I slightly change the code allowing me to take that line out, the program runs. The line in question is not actually encountered when runningroc run package/main.roc without extra arguments, but its existence seems to trigger the error regardless.
I've tried working around the problems for quite a bit:
Task returned from step.run from a tagged union to a Str.None of these worked though, and I'm taking shots in the dark because I don't have an intuition for what might be underlying problem.
I'd be happy to try create a minimal reproducible example of the bug, but I read in this related thread that more examples of this type of bug are not super useful.
I'm not sure what to try next, and would be super grateful for any help getting me unstuck. Even links to reading that would help me build an understanding of what's going wrong so I can try more informed workarounds would be super appreciated!
Richard Feldman (Mar 29 2024 at 13:38):hm, looks like the link is broken in this line :point_up:
Jasper Woudenberg (Mar 29 2024 at 13:48):Thank you! Fixed!
Luke Boswell (Mar 29 2024 at 20:13):I get three warnings (that I don't think I can do anything about)
This is #5477 which Agus is working on and the module params should fix.
Luke Boswell (Mar 29 2024 at 20:40):Spent some time playing with this and I haven't been able to find a workaround either. I think it might be related to having a function which returns a Task stored in a record.
Luke Boswell (Mar 29 2024 at 20:41):I'm wondering if you could re-architect to have the step funcs stored in a list, and then the step.run could be an index into that list?
Luke Boswell (Mar 29 2024 at 20:42):That might help by removing one less thing that could be causing an issue... but just an idea
Jasper Woudenberg (Mar 29 2024 at 22:10):Thank you for taking a look! I'm going to give the list approach a try, thanks for the idea!
Jasper Woudenberg (Mar 29 2024 at 23:26):I gave storing the functions in a list a try, but unfortunately the same error persists (pushed a fns-in-list branch). Doing that refactor did make me realize an unrelated aspect of the code could be simpler, so that was nice!
Brendan Hansknecht (Mar 31 2024 at 06:10):I think you probably need to rewrite this section of code in terms of Task.loop.
Brendan Hansknecht (Mar 31 2024 at 06:11):We have some bugs that currently tend to arise with manually walking lists of tasks to run them.
Brendan Hansknecht (Mar 31 2024 at 06:12):Might even need to rewrite the entire runSteps in terms of Task.loop
Jasper Woudenberg (Mar 31 2024 at 09:32):Thanks for the tip! I refactored runSteps to use Task.loop, and I think the code looks nicer now, though it's still failing when I attempt to run it with the same error as before.
Jasper Woudenberg (Mar 31 2024 at 15:13):To see what happens, I removed the loop entirely and ran the run function on just the first step in the list passed in, but this results in the same error. Based on that, I think the loop isn't culpable :).
Brendan Hansknecht (Mar 31 2024 at 15:18):Oh, surprising. Let me take a deeper look in a bit
Brendan Hansknecht (Mar 31 2024 at 17:15):Interesting. The cause is step.run.
Brendan Hansknecht (Mar 31 2024 at 17:20):Maybe is it somehow cause by the nesting of task related lambdas and then storage into the record....but why.
Jasper Woudenberg (Mar 31 2024 at 20:22):Yeah, trying to figure that out too. I've noticed that when I do the wrapping of the lambda in a datastructure and then call it directly after things seem fine, but if there's some more distance between the wrapping and calling then at some point it becomes a problem. Haven't figured out the exact threshold yet though.
Jasper Woudenberg (Apr 04 2024 at 19:59):I tried one other thing today, which was to replace cli-basic's Task with a custom type (something I want to do anyway at some point, to control what IO is possible in a step towards turning this into a platform). That didn't work though. Maybe not entirely surprisingly given it made the types more complicated rather than less.
Richard Feldman (Apr 12 2024 at 19:55):@Brendan Hansknecht do you have any ideas for how to work around this? seems like it's a blocker for the CI chapter
Brendan Hansknecht (Apr 12 2024 at 19:58):All I know is that it seems like your compiler doesn't like storing the task in a record. That might be a useful tip for debugging, but would have to mess around with it a lot more to have any concrete ideas.
Jasper Woudenberg (Apr 12 2024 at 20:44):I'm not blocked on the chapter, I think I could do most of the design and write the text, but would be nice if by the time we publish we could run it :sweat_smile:.
I'm not sure if it's the storing of the task in a record is the problem directly. If I create a wrapped task like that, and then use it "soon enough", then that's fine. It's when creating more distance between the wrapping and unwrapping that the problem starts occuring, but I've had trouble finding what border you need to cross to start running into the problem. I ran out of ideas last time I tried, will give it another go in a bit.
Last updated: Jul 26 2025 at 12:14 UTC