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

[GHC]

#10845: Incorrect behavior when let binding implicit CallStack object
-------------------------------------+-------------------------------------
        Reporter:  nitromaster101    |                Owner:  gridaphobe
            Type:  bug               |               Status:  patch
        Priority:  highest           |            Milestone:  8.0.1
       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):  Phab:D1422
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Ben Gamari <ben@…>):

 In [changeset:"3ec8288a18d57fb856e257905897daae237a1d5d/ghc" 3ec8288/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="3ec8288a18d57fb856e257905897daae237a1d5d"
 Rework the Implicit CallStack solver to handle local lets.

 We can't just solve CallStack constraints indiscriminately when they
 occur in the RHS of a let-binder. The top-level given CallStack (if
 any) will not be in scope, so I've re-worked the CallStack solver as
 follows:

 1. CallStacks are treated like regular IPs unless one of the following
    two rules apply.

 2. In a function call, we push the call-site onto a NEW wanted
    CallStack, which GHC will solve as a regular IP (either directly from a
    given, or by quantifying over it in a local let).

 3. If, after the constraint solver is done, any wanted CallStacks
    remain, we default them to the empty CallStack. This rule exists mainly
    to clean up after rule 2 in a top-level binder with no given CallStack.

 In rule (2) we have to be careful to emit the new wanted with an
 IPOccOrigin instead of an OccurrenceOf origin, so rule (2) doesn't fire
 again. This is a bit shady but I've updated the Note to explain the
 trick.

 Test Plan: validate

 Reviewers: simonpj, austin, bgamari, hvr

 Reviewed By: simonpj, bgamari

 Subscribers: thomie

 Differential Revision: https://phabricator.haskell.org/D1422

 GHC Trac Issues: #10845
 }}}

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