[GHC] #10845: Incorrect behavior when let binding implicit CallStack object

GHC ghc-devs at haskell.org
Mon Oct 5 00:26:09 UTC 2015


#10845: Incorrect behavior when let binding implicit CallStack object
-------------------------------------+-------------------------------------
        Reporter:  nitromaster101    |                Owner:  gridaphobe
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.11
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #10846            |  Differential Rev(s):
-------------------------------------+-------------------------------------
Changes (by gridaphobe):

 * related:   => #10846


Comment:

 Ok, the problem is that when we infer the type of a let-bound variable, we
 attempt to solve any constraints generated from the RHS without consulting
 the given constraints from the surrounding context. Specifically,
 `TcSimplify.simplifyInfer` tries to solve the wanteds with no givens.

 This is problematic for CallStacks because of the special rule that allows
 us to discharge a CallStack IP constraint without a given CallStack, by
 creating one out of thin air.

 So in

 {{{#!haskell
 f :: (?loc :: CallStack) => [(String, SrcLoc)]
 f = let y = getCallStack ?loc in y
 }}}

 the use of `getCallStack` tells GHC that `?loc :: CallStack`, and GHC
 immediately discharges the IP constraint without seeing the CallStack
 given by `f`'s context, while in

 {{{#!haskell
 f :: (?loc :: CallStack) => [(String, SrcLoc)]
 f = let y = ?loc in getCallStack y
 }}}

 we end up with a generic `?loc::t` constraint that GHC can't solve, until
 it emits an implication with `f`'s given constraints.

 I can work around this by splitting off any IP wanteds at the beginning of
 `simplifyInfer` and stitching them back onto the final implication
 constraint that `simplifyInfer` emits, but I'm not sure if this is the
 right solution. I don't think it should affect regular IPs since we always
 infer an IP constraint in local binders, but I still need to validate my
 patch.

 Also, I believe #10846 is closely related to this issue because
 `PartialTypeSignatures` triggers a similar code path through
 `TcBinds.tcPolyInfer` and `TcSimplify.simplifyInfer`, causing us to lose
 sight of the given IP constraint.

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


More information about the ghc-tickets mailing list