[GHC] #10493: Inaccessible code might be accessible with newtypes and Coercible

[GHC]

#10493: Inaccessible code might be accessible with newtypes and Coercible
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                   Owner:  goldfire
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.11
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by simonpj):

 That's the right place.  Currently we have
 {{{
   -- Fail straight away for better error messages
   -- See Note [Use canEqFailure in canDecomposableTyConApp]
   | isDataFamilyTyCon tc1 || isDataFamilyTyCon tc2
   = canEqFailure ev eq_rel ty1 ty2
   | otherwise
   = canEqHardFailure ev eq_rel ty1 ty2
 }}}
 I think you are proposing
 {{{
   | eq_rel == ReprEq && not (isDistinctTyCon tc1 && isDictinctTyCon tc2)
   = canEqFailure ev eq_rel ty1 ty2
   | otherwise
   = canEqHardFailure ev eq_rel ty1 ty2
 }}}
 That looks right, given the comment on `isDistinctTyCon`:
 {{{
 -- | 'isDistinctTyCon' is true of 'TyCon's that are equal only to
 -- themselves, even via coercions (except for unsafeCoerce).
 -- This excludes newtypes, type functions, type synonyms.
 -- It relates directly to the FC consistency story:
 --     If the axioms are consistent,
 --     and  co : S tys ~ T tys, and S,T are "distinct" TyCons,
 --     then S=T.
 }}}
 Tihs comment is vague about roles.  If we have a poof co :: S ~r T, and S
 and T are "distinct" then S=T.  But at what role is 'r'?  It would be
 helpful to clarify this comment in role vocabulary.

 Similarly the comment `Note [Pruning dead case alternatives]` in
 `Unify.hs` needs reviewing in the role world.  `Unify.typesCantMatch` is
 basically checking for apartness; which is also implemented somehwere
 else.  Can we combine?

 Simon

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