Visibility: handle multiple units with the same name
Fixes #16228 (closed). The included test case is adapted from the reproduction in the issue, and fails without this patch.
We compute an initial visilibity mapping for units based on what is present in the package databases. To seed this, we compute a set of all the package configs to add visibilities for.
However, this set was keyed off the unit's package name. This is not unique these days, since Cabal sub-libraries will have the same package name, but different ids.
The effect of this was that only one of the libraries in a Cabal package
would be added to this initial set. This would cause attempts to use
modules from the omitted libraries to fail, claiming that the package
was hidden (even though ghc-pkg would correctly show it as visible).
The solution is simple: key the map on the unit id instead of the package name.
Why wasn't this bug apparent to all people trying to use sub-libraries
in Cabal? The answer is that Cabal explicitly passes -package and
-package-id flags for all the packages it wants to use, rather than
relying on the state of the package database. So this bug only really
affects people who are trying to use package databases produced by Cabal
outside of Cabal itself.
One particular example of this is the way that the
Nixpkgs Haskell infrastructure provides wrapped GHCs: typically these
are equipped with a package database containing all the needed
package dependencies, and the user is not expected to pass
-package flags explicitly.