[GHC] #11062: Type families + hs-boot files = panic

[GHC]

#11062: Type families + hs-boot files = panic
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:
            Type:  bug               |               Status:  patch
        Priority:  high              |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  7.11
      Resolution:                    |             Keywords:  TypeFamilies
                                     |  hs-boot
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D2215
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 I'm going to respond  here to the comments on Phab:D2215 because I think
 Trac comments are more likely to survive long term than Phab discussion.

 The question is: ''where should we check for consistency of imported type-
 family axioms?''

 Currently it's done right after processing the import declarations of a
 module; but that's too early when we are concerned about consistency of
 axioms for a type family declared in this module.

 The patch does it late, after type checking all the local declarations.
 That's bad too, because all that type checking could be done with bogus
 overlapping family instances.

 I can think of two solutions.

 1.  Check for consistency of axioms for `F` ''right after `F` is
 defined''. That is, somewhere in `TcTyClsDecls.tcTyClGroup`.  Notes:
     * We'd still need to check consistency for ''imported'' families
 before we start typechecking anything.
     * With this more incremental behaviour it might be harder to optimise
 the number of pairs compared (see `checkFamInstConsistency` module-pair
 stuff).  But that doesn't matter since it is vanishingly rare for a type
 family defined in this module to have any imported instances whatsoever.


 2.  Make family-instance lookup complain if it finds two matching
 instances.
     * That would means we'd never make use of inconsistent instances,
 which would prevent strange error messages
     * We'd still need to do an aggressive `checkFamInstConsistency` check
 after type checking, to ensure consistency of instances that we didn't
 actually need when compiling this module (see the comments above
 `FamInst.checkFamInstConsistency`.

 I'm not sure which is best.  I think (2) looks a bit easier, and is quite
 close to the proposed patch; just needs an overlap check on lookup.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11062#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler