Re: [GHC] #14828: panic! when using :print on some functions with class constraints?

15 Mar 2019

      #14828: panic! when using :print on some functions with class constraints?
-------------------------------------+-------------------------------------
        Reporter:  jol               |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  GHCi              |              Version:  8.2.2
      Resolution:                    |             Keywords:  debugger
Operating System:  Linux             |         Architecture:  x86_64
 Type of failure:  Compile-time      |  (amd64)
  crash or panic                     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Marge Bot <ben+marge-bot@…>):

 In [changeset:"8162eab27101cddb0c822347300640f07110379a/ghc"
 8162eab2/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="8162eab27101cddb0c822347300640f07110379a"
 Remove the GHCi debugger's panicking isUnliftedType check

 The GHCi debugger has never been that robust in the face of
 higher-rank types, or even types that are _interally_ higher-rank,
 such as the types of many class methods (e.g., `fmap`). In GHC 8.2,
 however, things became even worse, as the debugger would start to
 _panic_ when a user tries passing the name of a higher-rank thing
 to `:print`. This all ties back to a strange `isUnliftedType` check
 in `Debugger` that was mysteriously added 11 years ago
 (in commit 4d71f5ee6dbbfedb4a55767e4375f4c0aadf70bb) with no
 explanation whatsoever.

 After some experimentation, no one is quite sure what this
 `isUnliftedType` check is actually accomplishing. The test suite
 still passes if it's removed, and I am unable to observe any
 differences in debugger before even with data types that _do_ have
 fields of unlifted types (e.g., `data T = MkT Int#`). Given that
 this is actively causing problems (see #14828), the prudent thing
 to do seems to be just removing this `isUnliftedType` check, and
 waiting to see if anyone shouts about it. This patch accomplishes
 just that.

 Note that this patch fix the underlying issues behind #14828, as the
 debugger will still print unhelpful info if you try this:

 ```
 λ> f :: (forall a. a -> a) -> b -> b; f g x = g x
 λ> :print f
 f = (_t1::t1)
 ```

 But fixing this will require much more work, so let's start with the
 simple stuff for now.
 }}}

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