[GHC] #13360: Add a flag to enable inferring HasCallStack constraints

GHC ghc-devs at haskell.org
Wed Mar 1 17:22:03 UTC 2017


#13360: Add a flag to enable inferring HasCallStack constraints
-------------------------------------+-------------------------------------
           Reporter:  gridaphobe     |             Owner:  (none)
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.0.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 GHC is careful to not infer a HasCallStack constraint for a function,
 because the user didn't ask for one, it would complicate the type, and
 because it would incur some runtime overhead. I think this is the right
 default, but it can make debugging exceptions tedious as you have to
 manually add HasCallStack constraints to the entire chain of functions in
 the stack. I sometimes use CPP to give myself a flag to toggle the
 constraints, but I'd rather not have to resort to CPP.

 Instead, it would be nice if GHC supported a `-finfer-hascallstack` flag
 (off by default) that would simply generalize over the HasCallStack
 constraints rather than defaulting them. Then, if my program blows up I
 can simply recompile with `-finfer-hascallstack` and get a more
 informative trace. No manual editing, no preparation with CPP, easy!

 Furthermore, if we had such a flag, it might be nice to '''enable''' it by
 default in ghci. The two prime concerns are

 1. Complicating type signatures. But `:t` solves the HasCallStack
 constraint before printing the type, so this is only a concern if you use
 `:i`.

 2. Runtime overhead. I don't think this is a valid concern in ghci.

 I think this would be a nice and simple improvement to the debugging
 experience.

 The downside is that even with `-finfer-hascallstack` you would not get
 full call-stacks for functions in an imported module that was compiled
 normally. So this would not help with e.g. partial functions in `base`.
 (It would be really nice to find a solution to this that doesn't involve
 building modules in multiple ways..)

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


More information about the ghc-tickets mailing list