[GHC] #8329: dmdTransformDictSelSig panic

[GHC]

#8329: dmdTransformDictSelSig panic
---------------------------------------+-----------------------------------
        Reporter:  monoidal            |            Owner:  simonpj
            Type:  bug                 |           Status:  new
        Priority:  highest             |        Milestone:
       Component:  Compiler            |          Version:  7.7
      Resolution:                      |         Keywords:
Operating System:  Unknown/Multiple    |     Architecture:
 Type of failure:  Compile-time crash  |  Unknown/Multiple
       Test Case:                      |       Difficulty:  Unknown
        Blocking:                      |       Blocked By:
                                       |  Related Tickets:
---------------------------------------+-----------------------------------

Comment (by Simon Peyton Jones <simonpj@?>):

 In [changeset:9bd366642f495fe26db261317dd416de1ff854bc/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="9bd366642f495fe26db261317dd416de1ff854bc"
 Lift an unnecessary assumption in the demand analyser (fix Trac #8329)

 Here's the Note about the (simple) fix.  Apparently #8329 prevented all
 23 packages of the Snap framework from compiling.

 Note [Demand transformer for a ditionary selector]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 If we evaluate (op dict-expr) under demand 'd', then we can push the
 demand 'd'
 into the appropriate field of the dictionary. What *is* the appropriate
 field?
 We just look at the strictness signature of the class op, which will be
 something like: U(AAASAAAAA).  Then replace the 'S' by the demand 'd'.

 For single-method classes, which are represented by newtypes the signature
 of 'op' won't look like U(...), so the splitProdDmd_maybe will fail.
 That's fine: if we are doing strictness analysis we are also doing inling,
 so we'll have inlined 'op' into a cast.  So we can bale out in a
 conservative
 way, returning topDmdType.

 It is (just.. Trac #8329) possible to be running strictness analysis
 *without*
 having inlined class ops from single-method classes.  Suppose you are
 using
 ghc --make; and the first module has a local -O0 flag.  So you may load a
 class
 without interface pragmas, ie (currently) without an unfolding for the
 class
 ops.   Now if a subsequent module in the --make sweep has a local -O flag
 you might do strictness analysis, but there is no inlining for the class
 op.
 This is wierd so I'm not worried about whether this optimises brilliantly;
 but
 it should not fall over.
 }}}

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