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