# SimplicityHL now reports more than one error per run

**URL:** <https://community.simplicity-lang.org/t/simplicityhl-now-reports-more-than-one-error-per-run/94>\
**Category:** SimplicityHL development\
**Created:** [October 16, 2026, 11:48am UTC](https://community.simplicity-lang.org/t/simplicityhl-now-reports-more-than-one-error-per-run/94 "2026-10-16T11:48:14Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![LesterEvSe](https://yyz1.discourse-cdn.com/flex007/user_avatar/community.simplicity-lang.org/lesterevse/32/67_2.png) [@LesterEvSe](https://community.simplicity-lang.org/u/LesterEvSe)\
**Post date:** [October 16, 2026, 11:48am UTC](https://community.simplicity-lang.org/t/simplicityhl-now-reports-more-than-one-error-per-run/94/1 "2026-10-16T11:48:14Z")

</div>

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:

```rust
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:

```plaintext
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](https://github.com/BlockstreamResearch/SimplicityHL/pull/185): chumsky parser, reports several syntax errors per run
- [#363](https://github.com/BlockstreamResearch/SimplicityHL/pull/363): `file_id` in every span
- [#369](https://github.com/BlockstreamResearch/SimplicityHL/pull/369): structured error types instead of strings
- [#370](https://github.com/BlockstreamResearch/SimplicityHL/pull/370): error rendering with ariadne

Analysis:

- [#417](https://github.com/BlockstreamResearch/SimplicityHL/pull/417): the `!` type
- [#418](https://github.com/BlockstreamResearch/SimplicityHL/pull/418): collecting errors
- [#420](https://github.com/BlockstreamResearch/SimplicityHL/pull/420): errors inside expressions
- [#424](https://github.com/BlockstreamResearch/SimplicityHL/pull/424): functions with broken bodies
- [#430](https://github.com/BlockstreamResearch/SimplicityHL/pull/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](https://github.com/BlockstreamResearch/SimplicityHL/pull/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](https://github.com/BlockstreamResearch/SimplicityHL/issues/178)), so errors point at the exact name.
- Poisoning in the parser ([#205](https://github.com/BlockstreamResearch/SimplicityHL/issues/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](https://github.com/BlockstreamResearch/SimplicityHL/issues/362). Comments are welcome there or here.