[GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms

[GHC]

#14218: GHC.Stack.HasCallStack not compatible with constraint synonyms
-------------------------------------+-------------------------------------
        Reporter:  ntc2              |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.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 Simon Peyton Jones <simonpj@…>):

 In [changeset:"abed9bf5008baf6b3e84251fe4d07de80c532ead/ghc" abed9bf/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="abed9bf5008baf6b3e84251fe4d07de80c532ead"
 Fix solving of implicit parameter constraints

 Trac #14218 showed that we were not solving implicit-parameter
 constraints correctly.  In particular,

 - A tuple constraint could "hide" an implicit-parameter wanted
   constraint, and that in turn could that we solved it from the
   wrong implicit-parameter binding.

 - As a special case the HasCallStack constraint (which is just
   short for (IP "callStack" CallStack), was getting mis-solved.

 The big change is to arrange that, in TcSMonad.findDict when looking
 for a dictionary, either when looking for a matching inert or solved
 dictionary, we fail for

   - Tuples that are hiding implicit parameters
     See Note [Tuples hiding implicit parameters]

   - HasCallStack constraints where we have not yet pushed
     on the call-site info
     See Note [Solving CallStack constraints]

 I also did a little refactoring

 * Move naturallyCoherentClass from Class to TcInteract, its sole
   use site.  Class.hs seems like the wrong place.  (And I also
   do not understand the reason that we need the eq/Coercible/
   Typable stuff in this predicate, but I'll tackle that separately.)

 * Move the code that pushes call-site info onto a call stack
   from the "interact" part to the "canonicalise" part of the solver.
 }}}

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