darklang / dark

Darklang main repo, including language, backend, and infra
https://darklang.com
Other
1.65k stars 90 forks source link

Tree-sitter-darklang: fix match_expr #5402

Closed OceanOak closed 1 month ago

OceanOak commented 1 month ago

No changelog

StachuDotNet commented 1 month ago

This PR updates match_case to work in the following way: if the rhs is an expression, it should be written in an indented block, or wrapped in parentheses

Why? Ideally, I wouldn't have to put a simple fn call in the next line or wrap in parens. I'm a bit confused what prompted this PR.

As a side-note, tuple_literal might be a simple_expression? edit: record-update might be OK as a simple_expression, too (the {} at either end wrap the expr contents well) edit: maybe qualified_const_name too?

OceanOak commented 1 month ago

Why? Ideally, I wouldn't have to put a simple fn call in the next line or wrap in parens. I'm a bit confused what prompted this PR.

Trying to parse the following is what prompted this PR

let parseConst (node: ParsedNode) : Result<WrittenTypes.Const, WrittenTypes.Unparseable> =
  match node.typ with
  | "consts" ->
    match node.children with
    | [ constNode ] -> parseConst constNode
    | _ -> createUnparseableError node

This ^ was parsing in a very odd way, and the issue only happens when we have nested match_exprs within a fn_decl

But you're right, I restricted it more than necessary. Adding support for an indented block in a match_case was enough to fix it.

As a side-note, tuple_literal might be a simple_expression? edit: record-update might be OK as a simple_expression, too (the {} at either end wrap the expr contents well) edit: maybe qualified_const_name too?

yes, those seems safe to move, thanks.