Stream: ideas

Topic: More tolerant block parsing

Sam Mohr (Sep 22 2024 at 08:31):

I've been feeling like we could do better in parsing incomplete code. Specifically, I'd love to do what Rust does with incomplete functions, which is add malformed AST nodes and continue parsing to allow the user to get diagnostics on the rest of their code, as opposed to our current approach of showing a single diagnostic at the top of the file explaining the parsing error.

To achieve this, for functions and assignment defs, we would need two things:

1. If there are no inner defs/expressions, fill in a malformed value that translates to a runtime error, and report the body as empty for that value.
2. If there are any statements/defs/expressions, if the last statement is not an expression, similarly add a malformed block node that translates to an AST node, and keep parsing

Sam Mohr (Sep 22 2024 at 08:35):

This should make implementing return statements easier, as well as making it easier to provide errors/warnings when early returns/crashes are present before other statements in a block.

Sam Mohr (Sep 22 2024 at 08:35):

I'm not actually sure when it's ever a desirable user experience for us to fail parsing in a module entirely instead of locally

Sam Mohr (Sep 22 2024 at 08:38):

Maybe on a malformed header? I don't think so

Anton (Sep 22 2024 at 08:46):

@Joshua Warner is probably interested in discussing this

Sam Mohr (Sep 22 2024 at 08:58):

Other places would be in empty control flow branches, a.k.a. if an if, else-if, else, or when ... -> had a similarly missing block or non-expression-terminated block

Sam Mohr (Sep 22 2024 at 09:02):

I could also see us wanting to fail early on invalid UTF-8, since that is annoying to have to handle across the entire parsing logic system

Sam Mohr (Sep 22 2024 at 12:27):

Here's maybe a third of the work done in a draft PR: https://github.com/roc-lang/roc/pull/7112

Sam Mohr (Sep 22 2024 at 12:27):

If we like the general approach, I can continue and polish up, add tests, etc.

Sam Mohr (Sep 22 2024 at 12:27):

If not, I'll ignore and continue to implement return sans cleanup

Sam Mohr (Sep 22 2024 at 12:41):

Small bit of context: in reading through our block parsing code, we actually have logic to fail parsing, not typechecking, on the wrong kinds of statements following others. For example, if an expression is seen that doesn't have a ! suffix, then we throw a parsing error for any following statements.

In line with the above goal, I think we should allow parsing any order of statements, and have warnings and errors instead during canonicalization

Joshua Warner (Sep 23 2024 at 02:13):

I like this goal

Last updated: Jun 16 2026 at 16:19 UTC