[GHC] #8809: Prettier error messages?
GHC
ghc-devs at haskell.org
Sun Jan 15 01:31:22 UTC 2017
#8809: Prettier error messages?
-------------------------------------+-------------------------------------
Reporter: joelteon | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.9
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking: 13122
Related Tickets: | Differential Rev(s):
#8809,#10073,#10179,#12906 |
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Rufflewind):
TBH, I think `SDoc` is too low level to embed rich semantic information
like expressions, locations etc. It should stick to what it does best:
laying out dumb text data. Instead, I think it'd be nicer to have a
simple high-level data type for diagnostics, which could look like:
{{{#!hs
data Error = Error Severity (Maybe ErrorID) ErrorMessage [(Location, Maybe
Expression)]
type ErrorID = String -- i.e. flag that disables the warning
-- it'd be nice to have them for errors too
type ErrorMessage = [ErrMsgSegment]
data ErrMsgSegment = EDoc SDoc | ELink Int -- link to some expression of
interest
}}}
… something along those lines. There's plenty of room to bikeshed on the
details, but it'd be great to keep it as simple as possible so as to
minimize the effort required by downstream to interpret the diagnostics.
In contrast, an `SDoc` does not give the consumer a lot of flexibility in
the display of an error.
This approach allows for a gradual transition: simply edit the legacy
error-emitting framework to emit an `Error severity Nothing (EDoc msg)
[(loc, Nothing)]`, which is the kind of “dumb” error that we have today.
To take advantage of the new system, we just bypass the legacy framework
and create `Error`s directly.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8809#comment:52>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list