Integrate HLint plugin

Integrate HLint into the IDE "loop".

[ndmitchell]

I think this should be a ghcide-hlint library separate to the core of ghcide. That would mean we need to split ghcide into ghcide-core (the majority of the library), so that ghcide can be the executable that imports ghcide-core and ghcide-hlint.

[cocreature]

The executable should technically be able to depend on a ghcide-hlint library even if we don’t split it into separate packages but various tools (looking at you nix) tend to fall apart if you have cycles at the package level even if there are no cycles at the component level so we probably still want to split it. I tend to agree that this is probably better as a separate library but we can put it in the same repo.

Leaving that aside there is also a technical issue here: HLint currently links against ghc-lib not ghc. This means that we would not be able to reuse the parse tree that we already have in ghcide. At least for 8.8 this is easily solvable on a technical level by just adding a cabal flag to switch the dependency from ghc-lib to ghc (Maybe that should even be the default in hlint, there seems to be little point in having to compile ghc-lib if you already have a version of the GHC API supported by HLint). Cabal flags have the issue that we cannot depend on a specific configuration of hlint so for this to not turn into a support nightmare, the default for GHC 8.8 would need to be to depend on ghc.

For GHC < 8.8, I see 3 solutions:

1. Make HLint support older GHC API versions. I have no idea how involved that would be.
2. Don’t reuse the parse tree but instead reparse using ghc-lib-8.8
3. Just disable HLint on those GHC versions.

2 sounds like asking for trouble and requires us to maintain different code for older GHCs which I’d like to avoid. 1 would be nice from a user standpoint but could potentially require a lot of work so I’d be tempted to just go with 3.

[ndmitchell]

Happy for HLint to use GHC on 8.8. Might cause some issues for @shayne-fletcher-da who needs to build HLint against GHC HEAD?

I'd suggest option 2, just reparse only on older GHC. By using the right extensions (which we have available), taking it after the preprocessor (which is the most fragile phase) and ignoring parse errors (which we know are spurious) we should be able to do a pretty good job.

[ndmitchell]

I think this would be a feature of https://github.com/haskell/ide, as per https://neilmitchell.blogspot.com/2020/01/one-haskell-ide-to-rule-them-all.html

[andys8]

One way to workaround and use ghcide with hlint is to diagnostic-languageserver. The advantage is that a client like CoC works better with multiple language servers than when the file is modified with an external tool/plugin.

hlint configuration

https://github.com/iamcco/diagnostic-languageserver/wiki/Linters#hlint

brittany configuration

https://github.com/iamcco/diagnostic-languageserver/wiki/Formatters#brittany

[alanz]

We are working on getting both of these integrated into haskell-language-server.

My hope is that we get some GSOC muscle thrown at it, and have something usable by the end of (northern) summer.

[andys8]

Thanks @alanz. I'm looking forward to the integration :) I'm currently switching a lot between ghcide, haskell-language-server and haskell-ide-engine. diagnostic-languageserver is only a workaround until the integration is done. Thanks for clarifying future plans.

[jneira]

hlint plugin is being integrating in hls (with its own issue there): haskell/haskell-language-server#166