Status of the rich errors proposal

Richard Eisenberg rae at richarde.dev
Mon Oct 28 21:37:24 UTC 2019


Ben Gamari is, I believe, leading the effort with that proposal. It continues to get attention but has not yet blossomed to something we're ready to debate widely. This is a hard nut to crack, and we'd like to get it right. So I guess all there is to say right now is that the effort is ongoing, but we don't have anything concrete to report at the moment.

Richard

> On Oct 23, 2019, at 7:52 AM, Javier Neira Sanchez <atreyu.bbb at gmail.com> wrote:
> 
> Hi, lately i am being collaborated in the haskell-ide-engine (hie) repo and one of the issues i get to fix was related with the parsing of ghc errors.
> It turns out that delimiters of terms in errors are different in windows (`term') and *nix (‘term’) systems and that drive to parse errors.
> Quite code actions and diagnostics are based in parsing them and they were broken in windows.
> I am afraid that the code is very brittle and close to human readable error messages. the actual code look like this:
> 
> -- | Extract a term from a compiler message.
> -- It looks for terms delimited between '‘' and '’' falling back to '`' and '\''
> -- (the used ones in Windows systems).
> extractTerm :: T.Text -> T.Text
> extractTerm txt =
>   case extract '‘' '’' txt of
>     ""  -> extract '`' '\'' txt -- Needed for windows
>     term -> term
>   where extract b e = T.dropWhile (== b)
>                     . T.dropWhileEnd (== e)
>                     . T.dropAround (\c -> c /= b && c /= e)
> 
> 
> or
> 
> extractImportableTerm :: T.Text -> Maybe (T.Text, SymbolImport SymbolType)
> extractImportableTerm dirtyMsg = do
>   (n, s) <- extractedTerm
>   let n' = T.strip n
>   return (n', s)
>   where
>     importMsg = S.headMay
>       -- Get rid of the rename suggestion parts
>       $ T.splitOn "Perhaps you meant "
>       $ T.replace "\n" " "
>       -- Get rid of trailing/leading whitespace on each individual line
>       $ T.unlines
>       $ map T.strip
>       $ T.lines
>       $ T.replace "* " "" -- Needed for Windows
>       $ T.replace "• " "" dirtyMsg
>     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]
> 
> It is clearly unsatisfactory but hard to improve without changing the messages to make it more structured.
> Moreover any legitimate change on errors to make it better will likely break it.
> 
> After exposing my worries in the hie irc channel, @mpickering pointed out that it is already a proposal to improve error messages:
> 
> https://github.com/bgamari/ghc-proposals/blob/rich-errors-proposal/proposals/0000-rich-errors-proposal.rst <https://github.com/bgamari/ghc-proposals/blob/rich-errors-proposal/proposals/0000-rich-errors-proposal.rst>
> 
> that nicely will improve the state of things.
> 
> Otoh there are already a way to output ghc errors as json (see https://gitlab.haskell.org/ghc/ghc/issues/13190 <https://gitlab.haskell.org/ghc/ghc/issues/13190>). It contains valuable info about the error in specific fields but the message itself is in plain text.
> So merging both features will let tools to handle compiler errors without use the ghc api directly if needed.
> 
> what is the status of the proposal? hie an other tooling developers will welcome it very heartly.
> 
> Thanks in advance!
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20191028/48be4099/attachment.html>


More information about the ghc-devs mailing list