Hi all,
Alfredo and I are hard at work redesigning GHC's error-message system. It is
time for more input, though, from clients of the system -- those writing IDEs
and other tooling on top of GHC.
The key question: How would you like your errors served?
Right now, errors are served well-done: fully cooked into structureless strings
that can be easily given to users. The problem with this is that IDEs cannot
easily intervene between GHC and the users, as all the nutrition (that is,
detailed information) has been cooked away.
The new design allows for *structured errors*, where error messages are
represented by elements of some error type. Different messages have different
constructors of this type, and these constructors can carry auxiliary
information. GHC will store these errors raw and cook them (that is, turn them
into readable strings) only right before printing them. If the raw messages
were somehow passed to IDEs, then IDEs could handle them non-uniformly. (For
example, if a module name and a file name are different, the IDE could just
present a dialog to the user asking whether the user would like to change one
automatically.)
There are a few open questions:
* In what vessel shall the raw messages be served? In other words, how do IDEs
expect to interact with this new system?
- One route would be to pass e.g. -fjson-errors, which means that GHC
presents the raw messages in a JSON format, for IDEs to parse. That's OK, but
it still means that IDEs would have to have their own raw error message types
to parse into.
- Another route would be for the IDE to link against GHC itself, and then
invoke the compiler via a function call that returns the raw messages directly.
- Another route is some kind of middle ground, where the IDE passes e.g.
-fbinary-errors=<filename> instructing GHC to write out a binary encoding of
its messages to some file (or pipe, I suppose). These could then be
deserialized back into GHC's own error types, but running in a separate process
(linked against GHC, once again).
- I'm sure you can come up with other interaction strategies.
* What will an IDE do with these messages? It might have special handling for
some, but GHC has a lot of different messages, and I imagine IDEs will want
many just to be printed to the user. If an IDE has only the raw message, then
the IDE is forced to do all the cooking -- no good. So there must be a way to
take a raw message and render it into a user-readable string.
- Maybe the above methods produce both the raw error and the rendered one?
Then the IDE can choose which it prefers to use.
- GHC could easily export its pretty-printing functions that take in the raw
messages and produce rendered ones. But that (again) requires linking against
GHC.
Note that we are not (here, yet) discussing errors served at points between raw
and well-done, though I would like to do so. Such an error would be rendered
into a format where textual bits are interleaved with more structured bits,
which would enable e.g. clicking on expressions within error messages to get
their types. That (important feature) comes separately.
So: what do consumers want here?
Preview: You can take a look at some raw error messages from the driver in
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533
<https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533>.
Thanks!
Richard
_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
