#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