[GHC] #10052: Panic (something to do with floatExpr?)

[GHC]

#10052: Panic (something to do with floatExpr?)
-------------------------------------+-------------------------------------
        Reporter:  edsko             |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.10.1-rc2
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Peter says (further)

 > Why do you say "we are clearly trying to float past a breakpoint"?  Why
 is it so clear?

 It's the only kind of `Tickish` that is scoped, counting and not
 splittable.

 This means that we can't
  * Simply float code out of it, because the payload must still be covered
 (scoped)
  * Copy the tick, because it would change entry counts (here: duplicate
 breakpoints)

 > Why is it wrong to float a lazy thunk out of a breakpoint?

 Good questions - I haven't given breakpoint semantics a lot of thought, to
 be honest. My assumption was that most optimisation passes would never see
 them. And where they did, they should just leave them in peace as much as
 possible.

 For whatever it's worth, the source cautions against making breakpoints
 unscoped:
 {{{
     -- Breakpoints are scoped: eventually we're going to do call
     -- stacks, but also this helps prevent the simplifier from moving
     -- breakpoints around and changing their result type (see #1531).
 }}}
 Hm. We might try to make them pseudo-splittable, with non-counting
 breakpoints being NOPs for now? This might still allow us to implement
 breakpoint-based stack traces if we really want them...

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