Feature request: improve error messages for missing lower bounds

[wenkokke]

See #8187.

Currently, when a package erroneously leaves out a lower bound on one of its dependencies, whether or not it builds correctly depends on the context in which it is used.

The package in the linked issue is missing a lower bound on the version of aeson (should be >= 2). It build correctly if the context in which it is used lets cabal pick a version >=2. However, if the context in which it is used pushes cabal to pick a version <2, the user is shown the following error message:

[11 of 16] Compiling Shoggoth.Metadata

shoggoth/Shoggoth/Metadata.hs:25:1: error:
    Could not load module ‘Data.Aeson.Key’
    It is a member of the hidden package ‘aeson-2.0.2.0’.
    Perhaps you need to add ‘aeson’ to the build-depends in your .cabal file.
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
   |
25 | import Data.Aeson.Key qualified as Key
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This error message is deeply confusing because aeson is verifiably listed in the build dependencies of the package. However, further inspection revealed that aeson-1.5.6.0 was used in the build plan, which indeed does not expose the module Data.Aeson.Key.

In this case, it might be good to include that information in the error message, e.g.,

Could not load module ‘Data.Aeson.Key’
    It is a member of the newer package ‘aeson-2.0.2.0’, but the older package `aeson-1.5.6.0` is used in the build plan.
    Perhaps you need to add the version constraint ‘>= 2.0.2.0’ to ‘aeson’ the build-depends in your .cabal file.

[gbaz]

This is a ghc error message that's getting passed through to cabal. I think possibly ghc could be more clever in this case, and change the "it is a member of a hidden package" message to note that a different version of that package is currently not hidden. However, ghc tries very hard (although it sometimes fails) to not think about versioning as such. I think error messages could be an exception.

[Mikolaj]

@bgamari, @mpickering: should we open this in GHC bug tracker? Any likely keywords to search if it's already open?