Integrate GHC's new diagnostic infrastructure

[kk-hainq]

In summary, GHC has changed how diagnostics are emitted that may break then further benefit HLint.
I think this integration is unavoidable in the long run. Maybe we can start from a branch that stages GHC HEAD support into HLint?
@ndmitchell Are you happy with this direction? We can start this work pretty soon.

References:

• errors-as-values proposal ghc-proposals/ghc-proposals#306
• https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values
• Integrate GHC's new diagnostic infrastructure haskell/haskell-language-server#2014

[ndmitchell]

I'm not sure how this impacts HLint at all. We don't really look at GHC diagnostics other than to pretty print them for parse errors, but that should be a few lines to pretty print a slightly different type instead, so seems a much smaller deal than the changes required for most GHC upgrades. Are you suggesting HLint should emit errors as structured errors? It doesn't at the moment, and I don't see much benefit to doing so. Curious what changes you think are required?

[kk-hainq]

Sorry if these ideas don't make sense, we're still just learning HLint!

My naive thought was that now the compiler errors/warnings are structured and we don't have to manually parse, can we show more suggestions for them? An example that has no compiler hints that we may add to:

{-| TcRnDodgyExports is a warning (controlled by -Wdodgy-exports) that occurs when a datatype
    'T' is exported with all constructors, i.e. 'T(..)', but is it just a type synonym or a
    type/data family.

   Example:
     module Foo (
         T(..)  -- Warning: T is a type synonym
       , A(..)  -- Warning: A is a type family
       , C(..)  -- Warning: C is a data family
       ) where

     type T = Int
     type family A :: * -> *
     data family C :: * -> *

   Test cases: warnings/should_compile/DodgyExports01
-}
TcRnDodgyExports :: Name -> TcRnMessage

With Name, we can hint and refactor T(..) to T here?

@ndmitchell If you think it's worth it, I think a good first step is for us to document all "potential" errors/warnings that we can add to HLint's arsenal.

[ndmitchell]

HLint doesn't parse GHC warnings and doesn't suggest refactoring T(..) or similar. You might be thinking of Haskell Language Server (https://github.com/haskell/haskell-language-server), which does the kinds of things you describe. HLS also integrates HLint for some hints, but not all the suggestions given by HLS are driven by HLint - all those related to warnings are in the HLS repo itself. I suggest raising this issue with HLS.

[kk-hainq]

I actually came here from the original task at HLS. I just happen to know people who don't use HLS in their setup (fewer and fewer nowadays though, and for the better!) so it may be fine to cross on simpler things. Let's keep this open until our team gets more familiar with both and comes up with more concrete ideas then.

[ndmitchell]

I think the thing is HLint has never consumed GHC errors, and is unlikely to start, but happy to leave this ticket open if you want.