Expose conditional modules (hard-coded)

[michivi]

This PR is a (dirty) workaround for an issue introduced by #2183, which effectively breaks Haskell project builds depending on packages re-exporting some of bases modules.

Technical description

The dummy-ghc-pkg-dump generated by lib/call-cabal-project-to-nix.nix describes GHC packages, most notably their dependencies, exposed modules and so on so forth. But it seems that the modules that are re-exported or conditionally exported (e.g., only exported when the target architecture is JavaScript, or exported when the target platform is Windows, or anything but Windows) are ignored. This can be problematic as some packages (e.g., our fork of base-noprelude) export some or all of bases modules, including the ones described earlier (e.g., the conditional GHC.Event here or the re-exported GHC.Num.Natural here). Because dummy-ghc-pkg-dump doesn't export those modules, attempt to build projects based on said packages will fail, with a failure similar to the following:

    Problem with module re-exports:
      - The module 'GHC.Num.Integer'
        is not exported by any suitable package.
        It occurs in neither the 'exposed-modules' of this package,
        nor any of its 'build-depends' dependencies.
      - The module 'GHC.Num.Natural'
        is not exported by any suitable package.
        It occurs in neither the 'exposed-modules' of this package,
        nor any of its 'build-depends' dependencies.
      - The module 'GHC.Num.BigNat'
        is not exported by any suitable package.
        It occurs in neither the 'exposed-modules' of this package,
        nor any of its 'build-depends' dependencies.
      - The module 'GHC.Event'
        is not exported by any suitable package.
        It occurs in neither the 'exposed-modules' of this package,
        nor any of its 'build-depends' dependencies.

Solution

This PR does not propose a long term fix. It's just a quick workaround for us to continue using haskell.nix, by including re-exported and conditional modules for very specific conditions. This is neither robust nor exhaustive. I've only focused on the cases we need.

Unfortunately, I don't see how to implement a more long term and exhaustive solution without actually interpreting the JSON condition to determine whether the modules should be included in the build or not. Perhaps a sister-executable to cabal2json?

To reproduce

To reproduce:

1. Start with commit dfd39f4 (Generate dummy-ghc from raw ghc source #2183)
2. Use Haskell.nix to build a project that includes a dependency that re-exports some base's modules (e.g., base-noprelude).
3. Attempt to build the project.
4. See that it fails with a message similar to the one described earlier
5. Include the patch from this PR
6. Attempt to build the project
7. See that the build succeeds

Also, please note that the build succeeds at point 7 only for commits preceeding 98830ce, which is #2203. It seems that this PR introduced another issue, but it's out of scope of this PR 🙂

Is this issue already known? Is there already a fix in the works? I can set up a repo with a sample code if required, I haven't done so neither have I worked further on a long term solution in case the issue is known and already fixed.

Thank you for your help 🙂