patch applied (ghc): Fix parent position in RnNames.nubAvails

[Manuel M T Chakravarty]

Simon Marlow:
> chak at cse.unsw.edu.au wrote:
> > Fri Oct 20 20:58:29 PDT 2006  Manuel M T Chakravarty <chak at cse.unsw.edu.au>
> >   * Fix parent position in RnNames.nubAvails
> >   - `RnNames.nubAvails', which amalgamates AvailInfo items that belong to the 
> >     same parent, needs to be careful that the parent name occurs first if it is
> >     in the list of subnames at all.  (Otherwise, we can get funny export items
> >     in ifaces.)
>  >
>  >   - I discovered this while debugging family import/exports, but I am pretty
>  >     sure the bug would also have shown up without using families under the
>  >     right circumstances.
> 
> I'm interested - what goes wrong if the parent doesn't occur first?  I noticed 
> that it often didn't when I was working on this code.  I checked and it was the 
> same in 6.4.2, so I assumed it must be ok, and I didn't encounter any problems 
> except that the pretty-printing code had to print out the parent name.

If it isn't first, then the parent is not removed from the subnames when
the AvailInfo is converted into its iface representation; ie, we get
things like "C{foo, C, T}" in the iface.  I am not sure whether there
are any bad consequences from this, other than confusing --show-iface
output, without type families.  With type families, you can get
RdrName.GlobalRdrElt values that when combined with RdrName.plusParent
trigger the assertion in plusParent, when reading ifaces with these
funny export items.

Manuel