Collect and report all errors across files

[LesterEvSe]

Project

errors

Motivation

Currently, the compiler reports the first error it hits, then stops. A user with five unrelated mistakes in their program has to run the compiler five times, fixing one mistake per run. With multi-file projects, this is multiplied by the number of files that contain errors.

Current State

We already have partial multi-error support — the lexer and parser collect multiple errors and recover well. The breakdown starts later: at the driver stage, error attribution is ambiguous, and the AST does not track file_id at all, so spans can point at the wrong file.

Goal

The goal of this issue is to bring together all the error-related issues and address them in a coordinated order, so the result is a compiler that:

1. Reports every error it can detect in a single run.
2. Attributes each error to the correct file.
3. Renders errors with ariadne instead of hand-written formatting
   code.
4. Keeps running passes after parsing on broken input instead of
   bailing on the first failure.

Execution plan

1. Refactor(ErrorHandler): Move file_id into Span and compute it during parsing #347 — Move file_id into Span and compute it at parse time.
   This removes the current "use a dummy id, then mutate later"
   pattern. Probably fixes ErrorHandler: Fails to report correct source file path for dependency AST errors #290 as a side effect; the PR should
   re-enable the regression test from ErrorHandler: Fails to report correct source file path for dependency AST errors #290 and confirm.
2. Refactor(ErrorHandler): Consolidate generic String errors into structured type #270 — Replace the remaining Result<T, String> returns
   with structured error types.
3. Refactor errors #204 — Migrate error rendering to ariadne. Implement the
   ariadne::Cache trait for SourceMap. Remove the hand-rolled
   formatting in Display for RichError.
4. Implement error states in parser #205 — Add error-state variants to the AST (for example
   Expr::Error, Type::Error) so passes after parsing can recognise
   recovered subtrees and skip them instead of crashing or producing
   cascading errors.
5. Error recovery in analysis #207 — Thread an error collector through the analysis passes so
   they accumulate errors instead of returning on the first one.
6. Refactor(ErrorHandler): Enhance error diagnostics for use item resolution #348 — Improve use item resolution diagnostics.

Steps 3 and 4 can be done in parallel after steps 1 and 2 are merged.

Relationship to existing issues

• Dependency, not absorbed: Track Span for other tokens on parsing stage #178 — span tracking for
  identifier-like tokens. It enables high-quality diagnostics that
  point at specific identifiers, but is a separate concern from
  collecting errors.
• Overlapping umbrella: Refactor parsing and analysis for better tooling support #191 already groups several
  tooling-related items. Its items 1 (identifier spans) and 3
  (multiple error outputs) overlap with this issue. I suggest updating that PR to reflect which of its items move under this umbrella and
  which stay.

Note: Feel free to suggest additions if I missed anything.

[LesterEvSe]

@apoelstra, @KyrylR, @delta1, @gerau let me know what you think?

[apoelstra]

Sounds great to me!

[KyrylR]

LGTM

[gerau]

Also, we should think about how to integrate warnings, related PR: #246

But aside from that LGTM

[LesterEvSe]

Okay, I will think about this