[GHC] #13102: orphan family instances can leak through the EPS in --make mode

[GHC]

#13102: orphan family instances can leak through the EPS in --make mode
-------------------------------------+-------------------------------------
        Reporter:  rwbarton          |                Owner:  rwbarton
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by rwbarton):

 I'm a bit unclear on both parts of the plan.

 * You write "special-case GHC.Exts so that it is always visible". Is this
 a code change? Are we keeping definition 2 for visibility of class
 instances for now? We don't really have to do anything about GHC.Exts for
 now, because:
     1. For class instance lookup, the `IsList` instances are already
 treated as visible because they are non-orphan.
     2. For type family instance lookup, the plan is to apply the same non-
 orphan rule as for class instance lookup, so the `Item` instances will be
 treated as visible too.
     3. For type family consistency checking, we need to make sure that
       a. All family instances that are made visible in this way are
 consistent with other visible instances. But there's no actual problem
 here, because in order to ''define'' an instance of `IsList` you still
 need to import `GHC.Exts`, and then `GHC.Exts` will be in the set of
 transitively imported family instance modules that gets checked for
 consistency. (The way there could have been a problem here is if the
 instances in question were non-orphan because they defined an instance
 that mentions a type defined in the module, of a type family that is
 defined in another module.)
       b. Since the desugarer is going to insert a call to
 `GHC.Exts.fromListN` into our module `M`, we also need to make sure that
 the definition of `fromListN` doesn't depend on some other type family
 instances that were visible in `GHC.Exts`, which might conflict with ones
 that are visible in our module `M`. But `fromListN` is just a class
 method, so surely there's no problem there either.

   In short, `GHC.Exts` is special-cased in the correctness proof, not in
 the compiler. But there could be other situations in which the arguments
 of 3a and 3b don't apply, so a better long-term plan is in order. And
 #13251 already gives an example.

 * "But, if we look at how the compiler handles finding instances of wired
 in things"...

   This sounds reasonable, but the problem here is not just about wired-in
 things. `IsList` is known-key, not wired-in; and the example using TH in
 #13251 is neither.

 In any case, since #13251 is its own ticket, I'll continue here with the
 short-term plan of using the same rules for type family instance
 visibility as for class instance visibility.

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