Alias analysis error in implementing `try` · compiler development

Stream: compiler development

Topic: Alias analysis error in implementing `try`

Sam Mohr (Nov 01 2024 at 03:47):

Hey all, I just put out a WIP PR for the try keyword implementation: https://github.com/roc-lang/roc/pull/7192

In short, it's typechecking (not super cleanly, but seemingly correctly), but the codegen runs into an alias analysis issue. I put a bit more detail into the PR, but in short, I think my translation from my new LowLevelTry(Expr) into a When expr in roc_mono::ir::with_hole is probably done wrong, or not the way to go.

Sam Mohr (Nov 01 2024 at 03:48):

The full description from the PR is:

I initially implemented this as a plain desugar to the above when expression, which worked, but wouldn't give very useful type errors. Instead, I'm implementing it as a new can::Expr, but I'm having alias analysis
Currently, typechecking is working properly (though there's some work to do there with respect to [Ok ok, Err err] vs. Result ok err), but codegen is failing at the alias analysis level. I think it has to do with my approach to compiling, which is the following:

After typechecking and during monomorphization, convert the try expression to a when expression in roc_mono::ir::with_hole.

For the missing type variables in the when expression (e.g. the type of the Ok ok ->), either:
a. type constrain variables during typechecking and use those
b. only constrain the required variables and synthesize the others using roc_derive::synth_var

I presume the alias analysis issue is with this approach. I'll keep trying to see if I can find the issue myself, but if anyone has any suggestions to fix, I'm all ears.

Sam Mohr (Nov 01 2024 at 03:49):

I have to leave to catch a movie, but tonight I'll be working on this again and will try to be available if anyone has ideas on how I could fix this. Thanks in advance!

Richard Feldman (Nov 01 2024 at 11:13):

might be worth landing as sugar first, and then splitting off the other approach

Richard Feldman (Nov 01 2024 at 11:13):

as a separate PR

Richard Feldman (Nov 01 2024 at 11:13):

it might end up working better on the new monomorphization and lambda set specialization branch I'm working on

Sam Mohr (Nov 01 2024 at 11:14):

Yeah, let me do that tomorrow

Sam Mohr (Nov 01 2024 at 11:14):

It'll be much faster to just merge sugar to unblock people

Sam Mohr (Nov 01 2024 at 11:15):

I just expect that, though you're probably right that your changes should decrease the likelihood of running into issues, I expect that I'm not specializing my generated types correctly

Sam Mohr (Nov 01 2024 at 11:15):

So I'll save my changes in a branch and we'll come back to them later

Sam Mohr (Nov 02 2024 at 00:38):

Okay, here it is: https://github.com/roc-lang/roc/pull/7193

Sam Mohr (Nov 02 2024 at 00:39):

I'll add tests either tonight or tomorrow morning.

Sam Mohr (Nov 02 2024 at 00:44):

Once I do this, I'll try to crack out the ? and ?? operators to finish the error handling suite, unless:

Someone else would rather do them
We'd rather keep them as simple tasks for new contributors

Sam Mohr (Nov 02 2024 at 00:44):

I'm okay with either of those!

Sam Mohr (Nov 02 2024 at 00:45):

Here are the (so far not commented on) issues:

Richard Feldman (Nov 02 2024 at 01:38):

Sam Mohr said:

Once I do this, I'll try to crack out the ? and ?? operators to finish the error handling suite, unless:

Someone else would rather do them

We'd rather keep them as simple tasks for new contributors

yeah let's hold off on those for now

Last updated: Jul 06 2025 at 12:14 UTC