-
Simon Marlow authored
Fix something that looks wrong in an attempt to get HEAD back on the rails again, whilst trying to get the award for the highest size-of-commit-message-to-number-of-lines-actually-changed ratio. The problem is this: a constructor defined as data T = A !Int will cause a DataCon wrapper to be generated like this: A = \x -> case x of x' { DEFAULT -> $wA x' } but the strictness on $wA says that it is strict in its first field. This is where the story gets a little hazy, but it seems that the compiler (5.00.2) happily removes the extra case thinking that x is going to get evaluated anyway, leaving us with A = \x -> $wA x and the argument to A ends up not being evaluated at all. Certain other parts of the compiler make use of the evaluatedness of fields in order to remove unnecessary cases, with the end result that we end up trying to dataToTag# an unevaluated thing, and certain derived Eq instances can give wrong results. Phew. Now, here's the bit I *don't* understand: I can only see the bug with 5.00.2, and only when the data type has more than one constructor: data T = A !Int | B nevertheless, the HEAD compiler when bootstrapped displays symptoms of a broken Eq instance, so I'm trying this fix to see if it helps. The Attempted Fix: give the DataConId a fully-lazy strictness signature.
89cb459a