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.