Please help to understand how compiler load the plugins. trying to implement a tool using GHC as library, where it’s not loading the plugins. Modified parseModule
function to call initializePlugins
which resolved the source but failing on typecheck. Any help would be appreciated.
2 Likes
Can anyone help in understanding the flow of how plugins are introduced on each step of GHC (8.8.4) pipeline.
Our use case is cabal build
is working fine. But when the same code is tried to be parsed with GHC library
the plugin is not being initialised.
Any help would be appreciated! Thanks
1 Like
opened 12:32AM - 22 Apr 19 UTC
closed 03:38AM - 25 Sep 19 UTC
ghc-8.6, when using the GHC API, requires that plugins be initialized explicitly… for each module. (Previous versions of the API initialized them automatically).
See for example:
https://github.com/sol/doctest/pull/224
The following file that uses `ghc-typelits-knownnat` can reproduce the problem. It builds fine with ghc-8.6, but fails to load in the indexer. I applied a patch on our internal codebase similar to the above doctest PR, but wasn't sure how to test it in this codebase given the external dependency requirement.
```
{-# OPTIONS_GHC -fplugin=GHC.TypeLits.KnownNat.Solver #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeOperators #-}
module Main (main) where
import Control.Exception (assert)
import Data.Proxy
import GHC.TypeLits
-- | Requires ghc-typelits-knownnat to solve its constraints:
plusOne :: forall n . KnownNat n => Proxy n -> Integer
plusOne _ = natVal (Proxy :: Proxy (n + 1))
two :: Integer
two = plusOne (Proxy :: Proxy 1)
main :: IO ()
main = assert (2 == two) $ return ()
```
The above issue helped. Tried it, it’s working now.
1 Like