haddock

haddock copied to clipboard

Currently, we use the ghc library, which chains us to a specific GHC version. However, ghc-lib-parser provides the exact same (as far as I can tell) interface, and would decouple us from GHC versioning concerns (at least by a considerable margin). Is there any reason why we couldn't do this?

Perhaps reconsider this after https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4778 lands?

@alanz I'm not as familiar with GHC's (or Haddock's) innards, so maybe I'm missing something, but won't that only land in the next release of GHC? That's 9.2 as far as I can tell, which is quite a while away at best. Secondly, how will this change the problem? ghc is the version-chained thing, and the MR is to the compiler itself.

Haddock still needs to use the GHC API for some non-parsing stuff right?

Haddock still needs to use the GHC API for some non-parsing stuff right?

Yes. At the very least, Haddock needs to be able to construct type signatures of top-level declarations for which the user did not specify a type signature. Doing that means using GHC in some way to reconstruct the type. Some other slightly less obvious places GHC gets used in Haddock:

• to resolve Name's so that hyperlinks go to the correct places
• to construct type-annotated hyperlinked sources
• to build up lists of instances
• to reify declarations which are re-exported (but have no local definition)

@poscat0x04 @harpocrates Is this functionality not coming from ghc or not available in ghc-lib-parser?

Anything to do with type checking probably isn't in ghc-lib-parser. The long-term goal of https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4778 is to make GHC actually modular, so rather than dealing with funny plugins and funny wrapper libs, we can just have a bunch of libraries, combined normally, just like the rest of the Haskell eocsystem.