#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: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind):
Display one line of code extracted from the original source code, along with a marker indicating the location of the error.
So this (“caret diagnostic” is what Clang calls them) is the one I'm a bit stuck on. In order to print a line in the original source file, I would need to read a file, i.e. perform `IO`. This is not possible with `ErrUtils.mkLocMessageAnn`, AFAICT. I thought of a workaround, but it would require a small tweak to `Doc`: I need to add an atom for `CaretDiagnostic` containing the `RealSrcInfo`, and then read the original source file in `printDoc`. However, I feel that this is a bit hacky. IMO, there should really be two layers in the system: - A `Message` type stores each individual diagnostic message unit along with an associated `SrcLoc` and any other useful information in their original format (e.g. fragments of the AST). - `Doc` should remain as a simple, textual output device with fancy formatting (no support for embedded ASTs). (It does need to understand colors and bold though, as their widths must be treated as zero.) The rendering function `[Message] -> IO Doc` would support `IO`, and this is where the caret diagnostics can be constructed, and it would also provide all the necessary information for `Doc` deduce alignment correctly. Hence, IMO the debate over how to represent ASTs should focus on the `Message` type, not `Doc`. That being said, even if this idea does work, I'm not sure I have the time to work on a major refactor right now, so I might go with the hacky solution for the time being. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8809#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler