Better compiler diagnostics (error messages, warnings, hints, etc.)

[anton-trunov]

There is a lot to be done in this area. I would say we should target the level of diagnostic achieved by Rust.

Also, here are some excellent references, collected by @ironcev while working on this RFC for the Sway smart contract language (thanks Igor <3).

• Expressive Diagnostics
• Shape of errors to come
• Compiler Errors for Humans
• Compilers as Assistants
• Concepts Error Messages for Humans
• Compiler Error Messages Considered Unhelpful: The Landscape of Text-Based Programming Error Message Research
• Usability improvements in GCC 8

[novusnota]

If anything, it would be nice to have unified structure for error messages, such that they can be reliably parsed in tools, such as tact.vim, tact-vscode or linters & such.

Maybe, as a first step on this path Tact should make either a programmatic (import {...} from '@tact-lang/compiler') or a CLI (tact --...) way to output all compilation issues (syntax, errors, etc.) in some machine-readable format (such as JSON, for example). That would remove the current need in parsing error messages by hand trying to match the moving target (#182), and thus drastically simplify the work for tool makers.

And once that done, proceed think about making unified and user-friendly messages for the stdout.

cc @anton-trunov @byakuren-hijiri @Gusarich what do you think?

[anton-trunov]

@novusnota Yes, having a centralized data structure for all error messages is what we should go for

[byakuren-hijiri]

@novusnota I agree that it would be great to have a structure designed to describe errors. This structure could be formatted for readability by humans or serialized into JSON to make output accessible for tools.

I think its format should be as simple as possible, since standard formats like SARIF seem too complicated.

[novusnota]

A good addition to that list:

• The Syntax Cliff, from Elm language blog — discusses how to make syntax error messages so nice, that they're actually tutoring the language to people!
• Error Message Catalog of Elm, where is a bunch of suggestions and implemented fixes (see closed issues) on error messages: their clarity, readability, preciseness.

There's another language, which also excels at developer experience — Gleam. I didn't see the them do similar discussions on error messages in their blog, though they are very concerned about good tools and convenience of using them and the language — take a look at their 1.0 release package: fledged language design, compiler, build tool, formatter, package manager, language server (LSP spec), and various bindings to WASM/JS. And all those are built-in the compiler binary! Plus, an interactive tour, like seen in Golang and Elm. Btw, it would be nice to make something similar in Nujan, although we have cool https://tact-by-example.org already.

Gleam has a bunch of other tools too, I'll post them here for completeness (and later reference):

• VSCode extension (as a wrapper around the language server binary)
• Tree-sitter grammar
• Vim support
• Emacs support
• And unofficial Sublime Text support

[novusnota]

If anything, it would be nice to have unified structure for error messages...

Suggestion: Start with parsing Ohm's syntax error messages, instead of simply adding additional info on top (grammar.ts). That way we'll have a structure for representing syntax errors inside the compiler, which may later get re-used for semantical errors, build errors, warnings or hints.

Because at the moment,output of check() from @tact-lang/compiler is not much different from Ohm's output, which isn't helpful for the programmer (at least in the following example):

P.S.: The syntax error with internal() instead of receive() is done intentionally :)