I understand this is sort of niche to the compiler development people; however, are there any diagnostics reporting libraries like miette for Rust? I could not find any from my searches.
I was able to create my own basic diagnostic reporter, but it does not support things such as inline notes with arrows in errors.
(I am definitely not trying to nerdsnipe anyone here, not at all)
One thing I observe about compiler diagnostics ecosystem is that:
there’s a strong desire to have rich, structured, nicely rendered errors
there’s no standard for such errors, which allows the tools to inter operate
To expand on the first bullet: these days, we expect the errors to be nicely rendered in the terminal, displayed in the editor, and also collected by the CI run. Historically, we used a common “gcc” flavor of error messages,
$file:$line:$column: $severety: $message
main.c:2:1: warning: return type of 'main' is not 'int'
and that was fairly inter-operable. Today, we moved beyond $message to structured errors, which have:
suberrors/notes
multiple spans of the source code
macro-expansion traces
numeric codes for googling
associated fixes
bug reporting url
read-the-manual url
To expand to the second bullet, although now the errors are rich, they are no longer interoperable. I can’t just pipe the rich output from the compiler into my editor and expect it to pick it up, because each language has its own way to render diagnostics. Many tools support JSON output, but every tool uses its own JSON format. There’s some common diagnostic format in LSP/BSP, but it doesn’t exist as a stand-alone format, usable by things which are not language servers/clients.
So, one improvement to state-of-the art here would be:
To design a language/presentation/serialization independent data model of what the error even is. I think this should be possible — although each programming language is different, most are file-based text-based languages developed in text-editors, so there’s a common constraint on what the error could be.
Then, design a set of presentations for this data model, which includes at least:
nice terminal rendering, with highlights, snippets and what-not.
JSON rendering, which is versioned, standardized, and can be a thin-waist between different tools
Language specific libraries to emit and consume this data model.
It was extremely simple and only showed the severity, associated line, and tildes under the designated area with only 50 lines of code. I guess it would be included in my parser code if I ever finish it.