[GHC] #11990: Custom Type Error not getting triggered in the nested Type function call

[GHC]

#11990: Custom Type Error not getting triggered in the nested Type function call
-------------------------------------+-------------------------------------
        Reporter:  magesh.b          |                Owner:  diatchki
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.0.2
       Component:  Compiler          |              Version:  8.0.1-rc3
      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 diatchki):

 Hello,

 sorry for the slow response---I didn't see this before.

 The current version does exactly what you've pasted so we are OK.
 Basically, each `TypeError` constraint becomes its own type error, and all
 of those should be reported as before.

 The comment about "picking just one type error" was referring to when a
 single type contains multiple errors. For example, consider the following:
 {{{
 g :: Proxy '[ TypeError (Text "A"), TypeError (Text "B") ]
 g = Proxy
 }}}
 This will generate just one of the type errors.  I am not sure if it might
 be better to generate all of them anyway, or if that would result in too
 many spurious errors...

 Even though your example works at the moment, it relies on a specific
 behavior of the GHC constraint solver that may change in the future.  In
 particular, currently GHC continues to reduce constraints, even though it
 found a constraint that is impossible to solve (i.e., the `TypeError`).
 If GHC was to become "lazier" in the future, you would only see one of
 those errors.

 A more robust way to get the same behavior would be to write a type
 function/class that analyzes the type and constructs an error message
 containing everything that went wrong, and then emitting just one type
 error.

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