Currently a ParseError is a single point with a message. It works for "expected ; here", but it can't express richer diagnostics like:
- "Unclosed
(" with a related span showing where it was opened
- "Missing closing quote" with a suggested insertion at the cursor
- "Did you mean
let?" as an actual editor fix, not just a hint message
I'd like to extend the error types with two lightweight fields:
type RelatedSpan = {
message: string
span: Span
}
type SuggestedFix = {
description: string
edits: { span: Span; replacement: string }[]
}
Then ParseError variants can carry related?: RelatedSpan[] and fixes?: SuggestedFix[].
This keeps us out of full compiler-diagnostic territory (no severity levels, no warnings) while still enabling much better error messages and future IDE / LSP integration. It pairs naturally with the Span overhaul in #X and the formatter refactor in #Y.
One thing to watch: when we merge errors from or(), we should probably drop related spans/fixes from non-primary attempts so the final message isn't noisy.
Currently a
ParseErroris a single point with a message. It works for "expected;here", but it can't express richer diagnostics like:(" with a related span showing where it was openedlet?" as an actual editor fix, not just a hint messageI'd like to extend the error types with two lightweight fields:
Then
ParseErrorvariants can carryrelated?: RelatedSpan[]andfixes?: SuggestedFix[].This keeps us out of full compiler-diagnostic territory (no severity levels, no warnings) while still enabling much better error messages and future IDE / LSP integration. It pairs naturally with the Span overhaul in #X and the formatter refactor in #Y.
One thing to watch: when we merge errors from
or(), we should probably drop related spans/fixes from non-primary attempts so the final message isn't noisy.