Stream: compiler development

Topic: Reporting a flurry of issues while migrating code

Niclas Ahden (Apr 17 2026 at 13:39):

Hey all! I've started migrating code over to the new compiler and have reported a few issues (#9342, #9344, #9349, #9350). @Anton has been on fire with these, thank you Anton! :)

I'm expecting to find a bunch more issues as I migrate more and more code. I want to move quickly with this because I've reached some limits with the old compiler and I'd like to help push the new compiler forward as much as possible.

A) Would it be helpful if I chucked Claude at the issues and posted PRs? I'm not a Zig programmer myself so I can't do a full review, but I can verify basic sanity and test coverage. I do ensure that my reports are narrow and detailed, so Claude may do a decent job, but I can't look out for architectural or long-term goals in this project as I'm too far removed (Zig + domain + new (to me) project).

B) Are issues regarding expect and roc test valuable at this time? I use them a lot and am finding a number of issues, but I'm happy to report those issues later and focus on the non-test aspects of the compiler first.

Anton (Apr 17 2026 at 14:15):

Thanks Niclas!

For A), I have done limited testing with opus 4.7 (xhigh effort), it may finally be ready for this. Opus 4.6 was often too lazy with its first fix.

B) Yeah, I don't see why not :)

Below is my prompt, make sure to replace /Users/username/gitrepos/zig with your local path to the zig repo (in that repo also do git checkout 0.15.2)

START PROMPT
Let's fix this:

<REPLACE BELOW WITH YOUR FAILING EXAMPLE>
❯ ./zig-out/bin/roc temp.roc --no-cache --opt=dev
1, 2 (correct)
3, 4 (incorrect)
5, 6 (incorrect)
5, 6 (incorrect)
any (correct)

roc on  fix-9344 [?] is 📦 v0.0.1 via 🦀 via ↯ v0.15.2
❯ ./zig-out/bin/roc temp.roc --no-cache --opt=interpreter
1, 2 (correct)
any (correct)
any (correct)
1, 2 (correct)
any (correct)

Follow these steps:

1. Investigate
2. Consider if there are multiple possible solutions.
3. Implement the best solution that solved the root of the problem, do your best to avoid quick and dirty fixes, fallbacks and workarounds.
4. Verify that the original problem is fixed.

general tips

That repo contains the Roc CLI, a compiler and interpreter written in zig.
You can rebuild the roc binary with zig build roc, this will put it in ./zig-out/bin/roc.

Searching:

• Very important: always exclude the crates folder (at the root of the repo) from all your searches, it contains the old compiler.
• The source code of zig 0.15.2 is in /Users/username/gitrepos/zig, you can use it as documentation.

Debugging:

• I encourage you to add debug prints and other necessary code to verify your hypothesis.
• You can enable printing of std.log.debug statements by altering the log_level at the top of src/cli/main.zig
• If you believe an issue is memory related, try building roc with refcount tracing: zig build roc -Dtrace-refcount

Style:

• Avoid using shortcuts, workarounds and special cases to get something to work. Avoid hardcoding things.
• Try to follow existing patterns in the codebase when applicable.
• Do not just change code when there are comments above it that explain the need for something to be done a certain way.
• Write high quality code, this is a production codebase.

If you encounter a network error when fetching dependencies, just run the command again.

Some zig commands do not output anything on success and just exit with code 0.

Note that zig test often does not work with our project, so we typically rely on zig build test, the flag --summary all can give your more info about which tests ran. You can run a single test with zig build test -- --test-filter "substring that occurs in test name". If you add --summary all it must be located before the -- --test-filter.

It's recommended to always run with --no-cache, so ./zig-out/bin/roc myfile.roc --no-cache, to prevent caching from behaving in unexpected ways.

Note that Roc has changed since your training data, it's recommended to check all_syntax_test.roc (and other .roc files if needed) if you're getting confusing errors when adding Roc code.

Very Important: when debugging, make sure you have found the root cause, and fix that, instead of trying to fix downstream symptoms. Do your best to avoid fallbacks and workarounds.

If you see an error like ld64.lld: error: cannot open test/fx/./platform/targets/arm64mac/libhost.a: No such file or directory, run zig build test-platforms -Dplatform=fx.

After you've done focused tests, run zig build minici to make sure you have not broken any other tests.
END PROMPT

Anton (Apr 17 2026 at 14:17):

You will probably need to install something for the coverage (kcov) step of zig build minici, just pass the error onto claude.

Richard Feldman (Apr 19 2026 at 14:50):

I think the main thing that's most helpful right now is PRs that add minimal tests reproducing bugs, starting from plain Roc syntax and ideally reproducing them in a test for the earliest compiler phase that reproduces the problem (e.g. if it's a type checking bug, adding a type checking test as opposed to a repl test, even though either would work - just because the repl tests are more expensive and don't add anything over a type checker test for a type checker bug!)

Richard Feldman (Apr 19 2026 at 14:52):

I've been working for almost a month on a big backend change (to make the backend a lot more like Ayaz's cor prototype) and failing tests are super helpful for verifying that it's getting the edge cases right!

Richard Feldman (Apr 19 2026 at 15:14):

and expect bugs are totally fair game!

Last updated: May 01 2026 at 12:45 UTC