Two bugs in rnExports (fixes Trac #5445)
authorSimon Peyton Jones <simonpj@microsoft.com>
Fri, 2 Sep 2011 08:20:45 +0000 (09:20 +0100)
committerSimon Peyton Jones <simonpj@microsoft.com>
Fri, 2 Sep 2011 08:22:10 +0000 (09:22 +0100)
commitfaadd61ef05e8f84a2ad7e0fb6b6d873a7b8c232
tree6ed27002cd8bdb92887893f3216bf55a5d633908
parente9f5a88a0b05991a0fe691027863ac8e3461e08a
Two bugs in rnExports (fixes Trac #5445)

When constructing export lists, data families pose an awkward problem,
documented in Note [Exports of data families] in RnNames.  Consider

   module M where
             import X( D )
             data instance D Int = M1 | M2

Here M exports M1 and M2, obviously, but does it export D?  It would
not usually do so, but if we don't then no one can import M selectively
like this:
           import M( D(M1,M2) )

So we compromise and export D too.  But I made two mistakes

a) Didn't check for conflicts between the extra export of X.D
   and any other exports called "D"

b) Did the extra export for imported things too, not just ones defined
   in this module (ie made the compromise apply much more widely than
   necessary)

This made Programatica (a complex project) break in an obscure
way; (b) caused an export conflict, (a) meant that the conflict
was not spotted, which in turn caused later chaos.

Anyway the fix is easy, and is documented in the Note.
compiler/rename/RnNames.lhs