GHC 9.4.2/Cabal 3.8.1.0 and PackageImports with reexported-modules - Problem

[mpilgrem]

I am having problems with GHC 9.4.2/Cabal-3.8.1.0 and PackageImports with Cabal's reexported-modules. I think what I am experiencing is a bug - I apologise if it is 'by design'. To explain:

I have a library in package my-package-B which exposes module LibB. I have a library in package my-package-A which build-depends on my-package-B and has reexported-modules LibB.

Finally, I have an executable in package my-package-C which build-depends on my-package-A (only), and has Main.hs:

{-# LANGUAGE PackageImports #-}

module Main (main) where

import "my-package-A" LibB (someFuncB)

main :: IO ()
main = print someFuncB

With stack --resolver ghc-9.2.4 build, it all builds as expected.

However, with stack --resolver ghc-9.4.2 build, and all else equal, the build fails with Cabal message:

my-package-C> app\Main.hs:6:1: error:
my-package-C>     Could not find module ‘LibB’
my-package-C>     Perhaps you meant
my-package-C>       LibB (from my-package-A-0.1.0.0, reexporting LibB)
my-package-C>       LibA (from my-package-A-0.1.0.0)
my-package-C>   |
my-package-C> 6 | import "my-package-A" LibB (someFuncB)
my-package-C>   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I can't make sense of the error message. I've requested LibB be imported from package my-package-A and I'm told it can't be found but perhaps I mean LibB reexported by my-package-A?

However, if I change (only) Main.hs to (no package-qualified import):

module Main (main) where

import LibB (someFuncB)

main :: IO ()
main = print someFuncB

stack --resolver ghc-9.4.2 build now works! That is why I think it is a bug.

[ulysses4ever]

Hey @mpilgrem and thanks for the report! I don't have any deep insight into it, but by the look of it, it feels like a GHC bug. Indicative of it is that changing the version of GHC can make the bug come and go. Do you think you could post this on the GHC's bug tracker to see what the folks over there have to say about it?

[ulysses4ever]

It does reproduces without stack, using cabal-install. Here's a repo with the project described in the report: https://github.com/ulysses4ever/cabal-t8548-package-import-fail Do a cabal build all on it: works with GHC 9.2, fails with 9.4.

[mpilgrem]

@ulysses4ever, I'm happy to raise it on GHC's issue tracker. What I was not sure about is that switching between GHCs also switches between the version of the Cabal library that ships with the version of GHC. With Stack I don't think I can decouple one from the other and I don't know enough about Cabal (the build tool) to comment.

[ulysses4ever]

@mpilgrem no, when you build your local project, GHC's boot Cabal version doesn't matter. It's your cabal-install or stack with whatever version of Cabal they were built that matters.

[mpilgrem]

@ulysses4ever, I am pretty sure Stack builds a Setup.exe with the version of Cabal that comes with the relevant version of GHC, and then uses that to interact with Cabal (the library). That is based, in part, on the Haddocks for Stack.Build.Execute.withSingleContext.

[ulysses4ever]

My bad, I’m very illiterate w.r.t stack and shouldn’t have guessed. On the other hand, I think that for cabal-install my claim still stands, and the bug reproduces with cabal-install.

[mpilgrem]

The GHC issue is here: https://gitlab.haskell.org/ghc/ghc/-/issues/22333

[mouse07410]

It does reproduce without stack, using cabal-install. Here's a repo with the project described in the report: https://github.com/ulysses4ever/cabal-t8548-package-import-fail . Do a cabal build all on it: works with GHC 9.2, fails with 9.4.

I confirm the reproducer on MacOS - fails with GHC-9.4.2, and passes with GHC-9.2.4.

[Mikolaj]

Let's block it on GHC until we know more.

[sgraf812]

https://gitlab.haskell.org/ghc/ghc/-/issues/22333 has been fixed. Close this issue?