SimplicityHL now reports more than one error per run

SimplicityHL development
1

Until recently, simc reported the first error in a program and stopped, so a program with several mistakes had to be fixed one compiler run at a time. Analysis now keeps going in many cases. Take this program:

type Alias = Missing;
fn f(a: Alias) -> Alias { a }
fn g(a: Undefined) -> Unknown { a }
fn h() -> u32 { y }

fn main() { let x: u32 = f(1); }

Previously, compilation stopped at Missing. On master you get all four mistakes in one run:

Type alias `Missing` is not defined
Type alias `Undefined` is not defined
Type alias `Unknown` is not defined
Variable `y` is not defined

Note: undefined types are replaced with !, so f(1) is not currently reported

Done so far

Groundwork:

  • #185: chumsky parser, reports several syntax errors per run
  • #363: file_id in every span
  • #369: structured error types instead of strings
  • #370: error rendering with ariadne

Analysis:

  • #417: the ! type
  • #418: collecting errors
  • #420: errors inside expressions
  • #424: functions with broken bodies
  • #430: undefined types

What still stops analysis

A failed statement still ends its block, a broken use ends analysis, and a file with a syntax error is not analyzed at all. The next steps:

  • Per-module error types with thiserror, building on gerau’s #324.
  • Recovery for statements and for the remaining items.
  • Poisoning for names: a failed use leaves a marker, so later uses of the name stay silent.
  • Spans for identifiers (#178), so errors point at the exact name.
  • Poisoning in the parser (#205). Today it fills syntax errors with defaults like 0 or an empty expression, which is why such files are not analyzed. Error nodes will replace them.

The full list and status are in #362. Comments are welcome there or here.

2 Likes
Multi-error reporting and raw_hash in the LSP and VS Code extension