Build failure in Haskell libraries using -fplugin flag

[Diamondy4]

Describe the bug

Build failure on installPhase on projects that use -fplugin=Some.Plugin.Module.Here flag in library's ghc-options.

Appeared after recent haskellPackages update that bumped default GHC to 9.6.
cabal build inside shellFor shell still working.

Failure log

Running phase: buildPhase
Preprocessing library for example-0.1.0.0..
Building library for example-0.1.0.0..
[1 of 1] Compiling Lib              ( lib/Lib.hs, dist/build/Lib.o, dist/build/Lib.dyn_o )
@nix { "action": "setPhase", "phase": "checkPhase" }
Running phase: checkPhase
Package has no test suites.
@nix { "action": "setPhase", "phase": "haddockPhase" }
Running phase: haddockPhase
@nix { "action": "setPhase", "phase": "installPhase" }
Running phase: installPhase
Installing library in /nix/store/qcmqhpfphzlc7ww25dgqv1rksi3dlgy6-example-0.1.0.0/lib/ghc-9.6.4/lib/x86_64-linux-ghc-9.6.4/exa>
Error: Setup: '/nix/store/p64ngk1v9d63lnrnyq0cynjd8jdk5jfa-ghc-9.6.4/bin/ghc'
exited with an error:
<command line>: Could not load module ‘GHC.TypeLits.Normalise’
It is a member of the hidden package ‘ghc-typelits-natnormalise-0.7.9’.
Perhaps you need to add ‘ghc-typelits-natnormalise’ to the build-depends in
your .cabal file.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.

Minimal failing example here.
Same example but on pre-default GHC 9.6 nixpkgs commit builds successfully with default GHC 9.4.

Steps To Reproduce

Steps to reproduce the behavior:

1. Add any GHC plugin to library's build-depends
2. Add that GHC plugin to library's ghc-options as "-fplugin=Some.Plugin.Module.Here"
3. Build it

Expected behavior

Successful build as it was before recent haskell-updates merge (before default GHC 9.6)

Additional context

Tested with effectful-plugin and ghc-typelits-natnormalise.

Notify maintainers

@NixOS/haskell @ncfavier @cdepillabout @expipiplus1 @maralorn @sternenseemann

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.8.4-cachyos, NixOS, 24.05 (Uakari), 24.05.20240403.fd281bd`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.21.1`
 - nixpkgs: `/nix/store/n2g5cqwv8qf5p6vjxny6pg3blbdij12k-source`

---

Add a 👍 reaction to issues you find important.

[maralorn]

That’s unsatisfying and maybe something we should have a regression test for.

[ncfavier]

Looks like this is haskell/cabal#9375, an issue with cabal that's fixed in 3.10.3.0 (GHC 9.10). I don't know how we work around it. See also commercialhaskell/stack#6251

[Diamondy4]

@ncfavier There is this haskell/cabal#9384 PR that should fix it. haskell.nix seem to use it too input-output-hk/haskell.nix#2101

[sternenseemann]

Adding an alternative Cabal that doesn't exhibit this issue to setupHaskellDepends should solve that issue. We can add that as a permanent workaround to `configuration-ghc-9.6.x.nix for affected packages.

[Diamondy4]

It should be applied to GHC 9.6-9.9, only 9.10 got it fixed.
It's also a fix for GHC core library - can it be applied with configuration-ghc-9.x.x.nix?

[sternenseemann]

@Diamondy4 such patches would need to be applied to the respective GHC derivation. Core libs are bundled with GHC.

[MangoIV]

@Diamondy4 9.6 is fixed since it got a release with the new cabal library. 9.8.3 is also on the radar but afaiu 9.10.2 and 9.12.1 are higher priority

[maralorn]

@MangoIV So our hope is, that 9.8.3 comes before stackage LTS switches to GHC 9.8?

[MangoIV]

I doubt that stackage is going to switch any time earlier as stack is affected by this as well.

[MangoIV]

But yeah, I think it would be problematic and we really need 9.8.3. I’ll comment under the issue.

[MangoIV]

Worst case is we have to patch our ghc, which is also not that bad?