Haskell-language-server: Multi component support

Created on 30 Jan 2020 · 19Comments · Source: haskell/haskell-language-server

This is something that is in hie, but not yet in ghcide, and is critical to encouraging existing hie users to switch over.

Source

alanz

Most helpful comment

And I understand @mpickering is now working on this.

alanz on 14 Feb 2020

🎉6

All 19 comments

The work is happening here https://github.com/digital-asset/ghcide/pull/361

alanz on 30 Jan 2020

🎉1

Mmm maybe i am wrong but afaiu in hie it was solved via cabal-helper, it has its own caveats but maybe it could be a better solution (see https://github.com/digital-asset/ghcide/pull/361#issuecomment-578486202)
could be added to ghcide itself? now that cabal-helper has a no copyleft license... :thinking:

jneira on 31 Jan 2020

My understanding is cabal helper is quite complex. What's the mechanism by which it solves multi components?

ndmitchell on 31 Jan 2020

As far as I know cabal-helper does not solve multi components. What it does is to give you a list of multiple components and their flags. You still have to figure out what to do with those flags. So in that sense, it is like an implicit hie-bios multi-cradle.

cocreature on 31 Jan 2020

Afaik, multi-components are solved via multiple HscEnvs (so, afaict very similar to the approach in https://github.com/digital-asset/ghcide/pull/361). CabalHelper does nothing except for finding the build-flags given a filepath. In fact, cabal-helper is only used in Cradle.hs.

fendor on 31 Jan 2020

Oh so i misunderstood it, sorry for the noise. cabal-helper only help (he) in make hie.yaml optional, true.

jneira on 31 Jan 2020

I had a crazy shower thought this morning. What if we run a separate sub-ghcid per component? As a full blown process.

alanz on 31 Jan 2020

Separate processes are even more wasteful than a separate HscEnv per component. The only upside is that you avoid issues like the global RTS linker but I don’t expect that to actually cause issues within things that are intended to be built together (as opposed to completely unrelated packages) and it’s already no longer global in GHC 8.10.

cocreature on 31 Jan 2020

Ok, that makes sense. As I said, it was an off-the-wall thought. My preference is a single executable.

alanz on 31 Jan 2020

alanz on 14 Feb 2020

And I understand @mpickering is now working on this.

alanz on 14 Feb 2020

🎉6

Hi. Seeing that today you released something, I finally decided to check this project out, with the hope that it would solve my problems related to TH.

However, in a multi-component project (several different cabal packages with one cabal.project) with correctly configured hie.yaml I am seeing this strange behavior:

[typecheck] [E] ROOT/code/morley-ledgers/src/Lorentz/Contracts/ManagedLedger/Doc.hs:27:16: error:
    Ambiguous occurrence ‘Markdown’
    It could refer to
       either ‘Lorentz.Markdown’,
              imported from ‘Lorentz’ at ROOT/code/morley-ledgers/src/Lorentz/Contracts/ManagedLedger/Doc.hs:21:1-14
              (and originally defined in ‘Util.Markdown’)
           or ‘Util.Markdown.Markdown’,
              imported from ‘Util.Markdown’ at ROOT/code/morley-ledgers/src/Lorentz/Contracts/ManagedLedger/Doc.hs:25:1-20
              (and originally defined
                 at ROOT/code/morley/src/Util/Markdown.hs:32:1-23)

As you can see, in this file I have Markdown coming from two different imports (Lorentz and Util.Markdown), but the first one is just a re-export of the second, so there is in fact only one type.

How can I help you debug this further?

maksbotan on 4 May 2020

@maksbotan I think this is a known bug where if you load multiple components you sometimes end up with incompatible interface files. Try deleting ~/.cache/ghcide