haddock

haddock copied to clipboard

GHC has changed so that plugins are only loaded once rather than just before each time they are used. I suspect that Haddock needs to follow this change and explicitly loads the plugins as well.

@christiaanb suggested some code like this in a suitable place would fix things.

https://github.com/clash-lang/clash-compiler/commit/8d32505b84a4f597bd995a4c39234b74be1b1e66#diff-c50e1570ba401340dde73490fed2c8cdR189

I suspect https://github.com/haskell/haddock/blob/1c4076328cfdd3aadbbbd494a240e25bd7309b0c/haddock-api/src/Haddock.hs#L428-L445

would be a good place for that.

This doesn't seem to work on Windows. See https://github.com/haskell/haddock/pull/905#issuecomment-431852530.

It doesn't work on (my) linux either.

Here is a simple testcase that fails with haddock-2.22.0 and ghc-8.6.2

It doesn't work on (my) linux either.

Here is a simple testcase that fails with haddock-2.22.0 and ghc-8.6.2

Thanks! doesn't work on my Mac either. I really like small test cases. 😄 I'll investigate.

I've been digging myself.

The documentation for initializePlugins says:

... Should be re-called if pluginModNames or pluginModNameOpts changes. ..

But is seems that the pluginModNames never gets set from the pragma.

The reason this works in clash is because we manually setup our plugins before we call initializePlugins, the plugins from the OPTIONS_GHC pragma aren't actually being used.

The DynFlags which contain the plugins are cached in the ModSummary of the ParsedModule.

Unpacking them, calling initializePlugins, and repacking everything up, kind of works. Like this: https://github.com/leonschoorl/haddock/commit/6dffdef6cd7a1ac5a982532fd9efcdc3d840ad3b There might be a better ways to do this through the GHC api, but I haven't found them yet.

And it fails to load local plugins like this: https://github.com/leonschoorl/haddock/commit/ee81152084ab23cf648ca29201d2bee3544fceec

Any news on this? I currently can't build the docs for my package locally because it uses typechecker plugins.

@leonschoorl Do you have a particular use case for local plugins? I'm tempted to just cherry-pick https://github.com/leonschoorl/haddock/commit/6dffdef6cd7a1ac5a982532fd9efcdc3d840ad3b for now, since it is definitely what we need for non-local plugins.

The issue about local plugins seems to be related to Haddock's forcing of hscTarget = HscNothing and ghcLink = NoLink. You can get the same panic (During interactive linking, GHCi couldn't find the following symbol...) by appending -fno-code to a regular ghc --make compilation for your example here: https://github.com/leonschoorl/haddock/commit/ee81152084ab23cf648ca29201d2bee3544fceec.

No I don't have a use case for local plugins, it's just something I stumbled upon when trying to write a test for this issue.

Just an experience report. Thanks for resolving this!

2.22.0 from Hackage failed to work for me. I eventually found this Issue. It took me a while to realize what to do, but I eventually cloned the 8.6-release branch, v2-intsalled that haddock Cabal project, and then successfully used v2-haddock --with-haddock=${HOME}/.cabal/bin/haddock in my actual Cabal project (in which one of the packages defines a plugin and the other packages uses it via {-# OPTIONS_GHC -fplugin ... #-} pragmas).

I've been working around this by enabling deferred type errors during haddock generation via cabal.project:

package my-package
  haddock-options: --optghc=-fdefer-type-errors

Going off of @leonschoorl's suggestions, if you are using stack, you can add this to your stack.yaml for a temporary workaround:

build:
  haddock-arguments:
    haddock-args:
    - --optghc=-fdefer-type-errors

I've also been stuck using GHC 8.4 because of this issue. I personally use ghc-typelits-natnormalise and ghc-typelits-knownnat for my work with type safe vectors. The aforementioned solution with deferred type errors unfortunately does not work for me.

Thanks for all your hard work, I just wanted to add a datapoint that some people do rely on this feature.

I just have stumbled again on this problem. Another workaround for multiple GHC versions is to add these haddock options via custom-setup Setup.hs. Useful for building a library, since it should work with both, stack and cabal-install.

To whom this may concern, I was able to fix my issues by using defer-type-errors. I had had my calls for the plugins listed in the cabal files directly, but moving them to OPTION_GHC pragmas in each module fixed the problem.

Hi, I met the same error with the option(--optghc=-fdefer-type-errors).

https://github.com/hasktorch/hasktorch/issues/177

I've had luck with --optghc=-fobject-code, as inspired by https://gitlab.haskell.org/ghc/ghc/-/issues/16093.

Looking at this comment trail, I am going to reopen this issue, as it seems people are still running into problems. In my use-case (and others?) the plugin is defined and used in the same package. My use-case is not "real" -- I am just trying to demonstrate the use of a plugin -- but there should still at least be a better error message in this case. Figuring this all out was quite non-trivial.