HaRe hie plugin api

[alanz]

Prepare haskell-ide-engine for a switch to the coming hie-bios by creating a Haskell.Ide.Engine.PluginApi module in hie-plugin-api which provides all the features needed by a very demanding plugin (HaRe).

The API exposed by this PR is

  -- ** Re-exported from ghc-mod via ghc-project-types
    GP.GmModuleGraph(..)
  , GP.ModulePath(..)
  , GP.GmComponent(..)
  , GP.GmComponentType(..)

  -- * IDE monads
  , HIE.IdeState(..)
  , HIE.IdeGhcM
  , HIE.runIdeGhcM
  , HIE.runIdeGhcMBare
  , HIE.IdeM
  , HIE.runIdeM
  , HIE.IdeDeferM
  , HIE.MonadIde(..)
  , HIE.iterT
  , HIE.LiftsToGhc(..)
  , HIE.HasGhcModuleCache(..)
  , HIE.cabalModuleGraphs
  , HIE.makeRevRedirMapFunc

  -- * Using the HIE module cache etc
  , HIE.setTypecheckedModule
  , HIE.Diagnostics
  , HIE.AdditionalErrs
  , LSP.filePathToUri
  , HIE.ifCachedModule
  , HIE.CachedInfo(..)

  -- * used for tests in HaRe
  , HIE.BiosLogLevel(..)
  , HIE.BiosOptions(..)
  , HIE.defaultOptions

None of these depend on ghc-mod(-core) directly, but the types related to the module graphs for each cabal component have been extracted from ghc-mod into a new ghc-project-types module. That name is provisional, if someone has a better suggestion, we can do it.

[alanz]

cc @mpickering

[mpickering]

It looks like the only function which will need any additional effort on my branch is HIE.cabalModuleGraphs. The first 4 ghc-mod types will probably have to be reconsidered slightly to avoid the cabal bias as well but shouldn't be too much effort.

[lukel97]

Is this meant to be a one-stop import for all plugins? If so should this also export the withCachedModule etc. functions and other helpers?

[alanz]

@bubba the initial intention is to create as narrow as possible an API to support what HaRe needs, as a way to end up with a real world requirement on hie-bios.

And I think there possibly still needs to be a discussion about what the layers are for a plugin.

My mental model for an external tool XXX currently has it something like

• hie
• plugin within hie to intergrate XXX to hie/LSP
• XXX as a standalone tool
• part of hie exposed to interact with GHC etc, and allow the tool to be a good citizen in hie, but also to be able to run standalone.

So this file is currently aiming at the last of those, which is effectively the hie-bios. I think.

But this whole layering is something that needs discussion, I think.

[michaelpj]

Perhaps we could view HIE as having two parts:

• A library for running long-lived sessions that provide access to processed information from GHC, in a relatively bulletproof fashion (i.e. using the hie-bios to work out how to talk to GHC)
  • Plugins could code against this library, and it would then also provide a way to run those tools in a relatively robust way. But they wouldn't have to have a dependency on a LSP client.
• A Haskell LSP client which uses the session library and manages plugins.

[alanz]

@michaelpj Do you mean LSP server in your comment above? The client is the IDE that talks to hie.

[michaelpj]

Er yes, sorry 🤦‍♂️

[alanz]

And the intended breakdown you describe is the driver behind having hie-plugin-api which should play the role described in your first bullet point, and does so for HaRe using this branch and https://github.com/alanz/HaRe/tree/hie-plugin-api.

But I can also envisage another layer, where a third party could package something like HaRe for hie, which can then be simply included in the plugin list in app/MainHie.hs and be usable.

So my original discussion point is whether we need to distinguish between the 'upper' and 'lower' APIs. Especially as I think there is likely to be some level of crossover in it.

[alanz]

@bubba can you please review especially d50a1b0.

The setTypecheckedModule function moved, I did a diff on the operational code and think I brought it over.

The tests do pass.

[lukel97]

This looks good to me. setTypecheckedModule was a very special function anyway, so moving out of the ghc-mod plugin makes sense in my eyes