Fix processing of imports involving ATs with the new name parent code
authorManuel M T Chakravarty <chak@cse.unsw.edu.au>
Fri, 20 Oct 2006 18:04:42 +0000 (18:04 +0000)
committerManuel M T Chakravarty <chak@cse.unsw.edu.au>
Fri, 20 Oct 2006 18:04:42 +0000 (18:04 +0000)
commit4f55ec2c7e78aa836b91ebc57ddd74675d92372c
tree5ba1c5ed4c52b27ebc990474cabe24a5702398a8
parent97236c9f9c903d01d99ada4e440fb9c37c6b27fd
Fix processing of imports involving ATs with the new name parent code

Associated types in import lists require special care and the new name
parent code broke that.  What's the problem?  in the presence of ATs
the name parent relation can have a depth of two (not just one as in H98).
Here is an example:

  class GMapKey a where
    data GMap a :: * -> *
  instance GMapKey Int where
    data GMap Int v = GMapInt ...

The data constructor GMapInt's parent is GMap whose parent in turn is the
class GMapKey; ie, GMapKey is GMapInt's grand parent.  In H98, data types
have no parents (which is in some places in the code represented by making
them their own parent).

I fixed this by extending the information in filterImport's occ_env and
taking the case of associated types explicitly in consideration when
processing the various forms of IE items.
compiler/basicTypes/OccName.lhs
compiler/basicTypes/RdrName.lhs
compiler/rename/RnNames.lhs
compiler/typecheck/TcRnDriver.lhs