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!
hm, looks like the link is broken in this line
:point_up:
Thank you! Fixed!
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.
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.
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?
That might help by removing one less thing that could be causing an issue... but just an idea
Thank you for taking a look! I'm going to give the list approach a try, thanks for the idea!
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!
I think you probably need to rewrite this section of code in terms of Task.loop.
We have some bugs that currently tend to arise with manually walking lists of tasks to run them.
Might even need to rewrite the entire runSteps
in terms of Task.loop
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.
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 :).
Oh, surprising. Let me take a deeper look in a bit
Interesting. The cause is step.run.
Maybe is it somehow cause by the nesting of task related lambdas and then storage into the record....but why.
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.
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.
@Brendan Hansknecht do you have any ideas for how to work around this? seems like it's a blocker for the CI chapter
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.
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 06 2025 at 12:14 UTC