plum

# Fix two pre-existing gaps: grammar trailing-statement limitation, codegen tail-position value drop

## Problem

Two real, pre-existing defects were discovered (and worked around, not fixed) while implementing

general enum support:

1. **Grammar**: a multi-line indented function/method body's `_statement` rule

   (`tooling/tree-sitter-plum/grammar.js:166-179`) only accepts `$.primary_expression` as one of

   its alternatives, not the full `$.expression`. A bare comparison (`a == b`), boolean operator

   (`a && b`), or ternary (`a ? b : c`) used as a statement — most commonly the final line of an

   indented body — fails to parse: the operator is dropped and the parser emits an `ERROR` node,

   silently splitting what should be one expression into two separate statements.

2. **Codegen**: `plum-wasm-codegen`'s `compile_block_as_fn_body` (`plum-wasm-codegen/src/lib.rs`)

   only preserves a function's return value when the body's *literal* last statement is a bare

   `ast::Stmt::Expr`. A `Stmt::If` or `Stmt::Match` in that same tail position compiles each arm as

   an ordinary statement block (`BlockType::Empty`), so a bare tail expression inside an arm is

   `Drop`ped instead of left as the function's result. This produces wasm that fails

   `wasmparser::validate` — a loud failure in the test suite, but `plum-cli`'s `compile` subcommand

   (`plum-cli/src/main.rs`) writes `compile_source`'s output bytes to disk without validating them,

   so a real user hitting this today gets a corrupt, unusable `.wasm` file with no error message at

   all, violating the README's stated guarantee that codegen "reports a clear error rather than

   silently producing wrong code."

Both were confirmed by direct reproduction during a prior session (parse-tree dump for gap 1;

`wasmparser::validate` failure plus a fixed reproduction using explicit `return` for gap 2).

## Fix 1: grammar

`$.expression` (`grammar.js:261-269`) is already a strict superset of `$.primary_expression`

(`grammar.js:271-285`) — every existing alternative reachable through `primary_expression` remains

reachable through `expression`, and `expression` is already used without incident elsewhere in the

grammar (`assign`'s values, `assert`, `return`, `if`'s condition). The fix is a single-line change:

```js

_statement: ($) =>

  choice(

    $.assign,

    $.break,

    $.continue,

    $.assert,

    $.for,

    $.while,

    $.if,

    $.match,

    $.return,

    $.todo,

    $.expression,   // was: $.primary_expression

  ),

```

Regenerate the parser and run the full existing corpus suite to confirm zero regressions (every

prior `primary_expression`-shaped statement remains valid, since `expression` accepts it too), then

add new corpus cases proving a bare comparison, boolean-operator, and ternary expression now parse

as a single statement with no `ERROR` node when used as a body's trailing line.

## Fix 2: codegen tail-position value propagation

Add a "value position" compile path that mirrors the existing `Stmt::Expr` special-case in

`compile_block_as_fn_body`, but recursively for `Stmt::If` and `Stmt::Match`:

- A `Stmt::If`/`Stmt::Match` in **value position** (the function body's literal last statement, or

  recursively the last statement of an `if`/`else if`/`else` branch or `match` arm that is itself in

  value position) compiles its condition/subject as today, but compiles each branch/arm using

  `BlockType::Result(result_vt)` instead of `BlockType::Empty`, and compiles that branch's own last

  statement through the same value-position path (recursing into further nested `If`/`Match`, or

  terminating at a bare `Stmt::Expr` — left on the stack, not dropped — or `Stmt::Return`/`Stmt::Todo`

  — already stack-polymorphic in wasm, since control never falls through past them).

- Every branch of a value-position `If` must have an `else` (a value can't be produced on a

  path that doesn't exist); every `match` arm must resolve to one of the shapes above. If any

  branch/arm's tail statement is some other shape (loop, assignment, etc.) that cannot yield a

  value, `compile_source` returns a clear `Err` (e.g. `"codegen: function 'f' has a control-flow

  path that doesn't produce a return value"`) — never silently falls through to today's

  invalid-wasm behavior.

- Existing callers of `compile_block_as_fn_body` are unaffected: the recursive value-position

  logic only activates when `has_return_value` is true and the function's tail statement actually

  is `If`/`Match` (today it already special-cases plain `Stmt::Expr`; this generalizes the same

  idea one level of control flow deeper). `If`/`Match` appearing anywhere *except* value position

  (e.g. as a non-tail statement, or a tail statement in a `Unit`-returning function) keep their

  existing, unchanged compilation path.

## Testing plan

- **Grammar**: extend `tooling/tree-sitter-plum/test/corpus/` with cases for a bare comparison,

  boolean-operator, and ternary expression as a body's trailing statement; run the full corpus

  suite to confirm no regressions.

- **Checker**: no changes are needed to `plum-checker` for either fix (both are purely

  parser/codegen concerns) — but re-run the full checker suite (including `examples_test.rs`) to

  confirm nothing regresses, since the grammar change affects what `plum-core`'s parser produces.

- **Codegen**: add tests (`plum-wasm-codegen/tests/codegen_tests.rs`) executing (via `wasmtime`,

  not just validating) functions whose tail statement is: a `match` with bare-expression arms and

  no explicit `return` (the original `examples/match.plum` shape that motivated this work); an `if`

  with bare-expression branches and no explicit `return`; a *nested* `if` inside a `match` arm

  (recursion through both control-flow kinds); a mix of one arm using explicit `return` and

  another using a bare tail expression (validates the stack-polymorphism claim); and a

  deliberately malformed case (a `match` arm whose tail statement is e.g. a bare `Stmt::Assign`)

  asserting `compile_source` returns the new clear `Err` rather than ever producing bytes.

- **Examples**: revert the `return`-adding workaround applied to `examples/match.plum`'s five

  functions back to their natural bare-tail-expression form (proving the fix actually restores the

  originally-intended, more idiomatic style) and confirm `plum-wasm-codegen/tests/examples_test.rs`

  still passes.

- **README**: remove the now-fixed "final statement being a match/if without explicit return"

  bullet from Known Gaps.

## Out of scope

- General "does every code path return a value" checking beyond what's needed to make

  value-position `If`/`Match` either compile correctly or fail with a clear error — this is not a

  full control-flow/definite-assignment analysis in `plum-checker`, just a defensive check inside

  the new codegen path.

- `plum-cli`'s `compile` command validating its own output before writing to disk — worth doing

  separately, but this fix makes the underlying codegen bug (the actual source of the corrupt

  output) go away rather than adding a downstream safety net. Not required for this fix to be

  complete, since the root cause is resolved.

- Generics monomorphization — a separate, much larger effort, tracked independently.