Skip to content

GHC 9.6.3 can't find GHC plugin modules that `ghc-pkg` 9.6.3 and GHC 9.4.7 can find

Summary

Code that uses GHC plugins works fine with GHC 9.4.7/Cabal-3.8.1.0, but bumping to GHC 9.6.3 (or 9.6.2)/Cabal-3.10.1.0 (and making no other changes) GHC behaves as if it cannot find the plugin module - see further below. I do not know if this is a bug introduced into GHC 9.6, or a bug introduced into Cabal 3.10.1.0, or a Stack bug revealed only by GHC 9.6/Cabal-3.10.1.0. As far as I can tell, in moving from GHC 9.4.7/Cabal-3.8.1.0 to GHC 9.6.3/Cabal-3.10.1.0, Stack is providing the same commands to Cabal (the library) and, in turn, Cabal is providing the same commands to GHC. I have not identified any relevant documented change between GHC 9.4.7 and GHC 9.6.3 or between Cabal-3.8.1.0 and Cabal-3.10.1.0.

Steps to reproduce

The context is described on the Haskell Community with one GHC plugin. I have recently also experienced it with another, here. So, I do not think it is related to the plugins themselves.

For example, a single-package project has src/A.hs:

{-# LANGUAGE DataKinds #-}
module A where

import Polysemy
import Polysemy.State
import Prelude

f :: Sem '[State Int] ()
f = pure ()

and Cabal file:

cabal-version:  1.12
name:           problematic
version:        0.0.0.0
build-type:     Simple

library
  exposed-modules: A
  hs-source-dirs: src
  ghc-options: -fplugin=Polysemy.Plugin
  build-depends:
      base
    , polysemy
    , polysemy-plugin
  default-language: Haskell2010

With GHC 9.4.7/Cabal 3.8.1.0 it builds: stack --resolver lts-21.13 build.

Simply switching to GHC 9.6.3/Cabal 3.10.1.0 it fails (stack --resolver nightly-2023-10-01 build), at the point that Cabal (the tool) tries to register the library with GHC. The error is (with --ghc-options -v, for extra GHC information) (extracts):

problematic> build (lib)
Preprocessing library for problematic-0.0.0.0..
Building library for problematic-0.0.0.0..
problematic> copy/register
Installing library in D:\Users\mike\Code\Haskell\problematic\.stack-work\install\feba0381\lib\x86_64-windows-ghc-9.6.3\problematic-0.0.0.0-COPLr0VCarzjTvJWKNtAI
Error: Cabal-simple_9p6GVs8J_3.10.1.0_ghc-9.6.3.exe:
'D:\sr\programs\x86_64-windows\ghc-9.6.3\bin\ghc-9.6.3.exe' exited with an
error:
Glasgow Haskell Compiler, Version 9.6.3, stage 2 booted by GHC version 9.4.3
*** Deleting temp files:
Deleting:
*** Deleting temp subdirs:
Deleting:
*** Deleting temp dirs:
Deleting:
<command line>: Could not find module ‘Polysemy.Plugin’
Locations searched:
.stack-work\dist\6c8505b4\build\Polysemy\Plugin.hi
.stack-work\dist\6c8505b4\build\Polysemy\Plugin.hi-boot

Why GHC 9.6.3 (and, I assume, not GHC 9.4.7 - I don't know where GHC 9.4.7 is searching because that information is only provided by GHC if there is an exception) is looking in .stack-work (and only there) is a mystery to me. ghc-pkg 9.6.3 in the Stack environment, for example, knows that Polysemy.Plugin is to be found in the snapshot (extracts):

> stack --resolver nightly-2023-20-01 exec -- ghc-pkg find-module Polysemy.Plugin
D:\sr\programs\x86_64-windows\ghc-9.6.3\lib\package.conf.d
    (no packages)
D:\sr\snapshots\3a278357\pkgdb
    polysemy-plugin-0.4.5.1

D:\Users\mike\Code\Haskell\problematic\.stack-work\install\feba0381\pkgdb
    (no packages)

If I were to speculate, it is as if GHC 9.6.3 is ignoring the contents of the GHC_PACKAGE_PATH environment variable when it looks for GHC plugin modules.

Expected behavior

That GHC 9.6.3 behave like GHC 9.4.7.

Environment

  • GHC version used: 9.6.2 and 9.6.3

Optional:

  • Operating System: Windows 11
  • System Architecture: x86_64
Edited by Mike Pilgrem
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information