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

```bash 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: : 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 :+1: 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 https://github.com/haskell/cabal/issues/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 https://github.com/commercialhaskell/stack/issues/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?