What changes to GHC error reporting are required

[alanz]

There are a number of trac tickets related to the way GHC reports errors, with a view to improving them.

https://ghc.haskell.org/trac/ghc/ticket/8809
https://ghc.haskell.org/trac/ghc/ticket/10073
https://ghc.haskell.org/trac/ghc/ticket/10179

For tooling support, there should be an option to return errors in some kind of typed structure that can be easily an unambiguously processed by the tool.

This is in general a hard task, with deep tentacles into GHC.

Is there any low hanging fruit we can harvest in time for GHC 8.1?

[gracjan]

Important part of error message is the cross referencing information point to related files and lines of code. gcc and clang always put file name and line number as first information in output line:

file.cpp:12: ambiguous symbol 'xxx'
file.h:12: from a file included here
header.h:444: from a file included here

Sadly GHC likes to put paths to source files inside sentences so we have to discover where is the cross referencing information.

[mgsloan]

It would be great to have -fdefer-type-errors prepend something to the warnings which are outputted for errors (maybe "Error: "). I'd like to have -fdefer-type-errors be a default, but still present the messages as if they were errors.

[alanz]

I think there has been a change to prepend "error", will be in 8.0.1, may
be in 7.10.2 already

On Tue, Oct 27, 2015 at 12:41 AM, Michael Sloan notifications@github.com
wrote:

It would be great to have -fdefer-type-errors prepend something to the
warnings which are outputted for errors (maybe "Error: "). I'd like to have
-fdefer-type-errors be a default, but still present the messages as if
they were errors.

—
Reply to this email directly or view it on GitHub
#7 (comment).

[cocreature]

One thing that I keep stumbling upon is the fact that suggestions to enable pragmas always have slightly different formats causing tools which try to parse them such as haskell-mode to not recognize them in a lot of cases.

[nponeccop]

What about .cabal errors? Now there are errors which are returned without any file position information, so we can't put them as diagnostics.

[jneira]

As pointed by @mpickering there are a ghc proposal to implement structured errors: https://github.com/bgamari/ghc-proposals/blob/rich-errors-proposal/proposals/0000-rich-errors-proposal.rst. It is pretty recent (3 months).

To fix some bugs for windows i had to add more cases in parsing human readable ghc errors:

haskell-ide-engine/test/functional/FunctionalCodeActionsSpec.hs

Lines 224 to 228 in 5385087

	let prefixes = [ "Could not load module `Data.Text'" -- Windows && GHC >= 8.6
	, "Could not find module `Data.Text'" -- Windows
	, "Could not load module ‘Data.Text’" -- GHC >= 8.6
	, "Could not find module ‘Data.Text’"
	]

or

haskell-ide-engine/src/Haskell/Ide/Engine/Plugin/HsImport.hs

Lines 489 to 501 in 5385087

	extractTerm prefix symTy =
	importMsg
	>>= T.stripPrefix prefix
	>>= \name -> Just (name, Import symTy)
	extractType b =
	extractTerm ("Not in scope: type constructor or class " <> b) Type
	extractedTerm = asum
	[ extractTerm "Variable not in scope: " Symbol
	, extractType "‘"
	, extractType "`" -- Needed for windows
	, extractTerm "Data constructor not in scope: " Constructor]