#16377: `TypeError` in a pattern should flag inaccessible code

#16377: `TypeError` in a pattern should flag inaccessible code
-------------------------------------+-------------------------------------
           Reporter:  diatchki       |             Owner:  (none)
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.6.3
  (Type checker)                     |
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 When we pattern match, if the context ends up having a custom `TypeError`,
 we should probably report it, as we've essentially found some inaccessible
 code.   At present this doesn't happen and the custom error is only
 triggered if the function is applied to an invalid argument.  Here is an
 example to illustrate the issue:

 {{{
 {-# LANGUAGE ConstraintKinds #-}
 {-# LANGUAGE DataKinds #-}
 {-# LANGUAGE KindSignatures #-}
 {-# LANGUAGE TypeFamilies #-}
 {-# LANGUAGE UndecidableInstances #-}
 {-# LANGUAGE GADTs #-}

 module Test where

 import GHC.TypeLits
 import Data.Kind(Constraint)

 type family F a :: Constraint
 type instance F Int  = ()
 type instance F Char = TypeError ('Text "Nope")
 type instance F Bool = (Int ~ Char)

 data T where
   A :: F Int  => T
   B :: F Char => T
   C :: F Bool => T

 exhaustive :: T -> ()
 exhaustive A = ()
 exhaustive B = ()   -- this is not flagged as inaccessible, but it should
 -- exhaustive C = ()   -- this is flagged as inaccessible, as expected
 }}}


 If the match with constructor `C` is added to the program, GHC detects
 that this equation is inaccessible because `Int` will never match `Char`.
 I think that we'd like the same to happen in the second equation when we
 match on `B`, except we should report the custom type error, instead of
 GHC's message about unreachable code.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16377>