Fix Trac #7237; mixup with empty tuples
authorSimon Peyton Jones <simonpj@microsoft.com>
Sat, 15 Sep 2012 22:06:20 +0000 (23:06 +0100)
committerSimon Peyton Jones <simonpj@microsoft.com>
Sat, 15 Sep 2012 22:06:20 +0000 (23:06 +0100)
When converting from Core to STG, we swith pattern matching on
on a *nullary* unboxed tuple into matching using a PrimAlt on RealWorld#
   case e (RealWorld#) of { DEFAULT -> ... }
This semms messy to me, but it works.  There was a bug in that we were
changing to PrimAlt, but not using a DEFAULT AltCon.

compiler/stgSyn/CoreToStg.lhs
compiler/types/Type.lhs

index 6dc0919..eed579e 100644 (file)
@@ -36,6 +36,7 @@ import Maybes           ( maybeToBool )
 import Name             ( getOccName, isExternalName, nameOccName )
 import OccName          ( occNameString, occNameFS )
 import BasicTypes       ( Arity )
+import TysWiredIn       ( unboxedUnitDataCon )
 import Literal
 import Outputable
 import MonadUtils
@@ -420,6 +421,14 @@ coreToStgExpr (Case scrut bndr _ alts) = do
       )
   where
     vars_alt (con, binders, rhs)
+      | DataAlt c <- con, c == unboxedUnitDataCon
+      = -- This case is a bit smelly. 
+        -- See Note [Nullary unboxed tuple] in Type.lhs
+        -- where a nullary tuple is mapped to (State# World#)
+        ASSERT( null binders )
+        do { (rhs2, rhs_fvs, rhs_escs) <- coreToStgExpr rhs
+           ; return ((DEFAULT, [], [], rhs2), rhs_fvs, rhs_escs) }
+      | otherwise
       = let     -- Remove type variables
             binders' = filterStgBinders binders
         in
@@ -463,7 +472,7 @@ mkStgAltType bndr alts = case repType (idType bndr) of
                                         PolyAlt
         Nothing                      -> PolyAlt
     UbxTupleRep rep_tys -> UbxTupAlt (length rep_tys)
-
+    -- NB Nullary unboxed tuples have UnaryRep, and generate a PrimAlt
   where
    _is_poly_alt_tycon tc
         =  isFunTyCon tc
index 6a38030..4e8e631 100644 (file)
@@ -612,14 +612,14 @@ newtype at outermost level; and bale out if we see it again.
 
 Note [Nullary unboxed tuple]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-We represent the nullary unboxed tuple as the unary (but void) type State# RealWorld.
-The reason for this is that the ReprArity is never less than the Arity (as it would
-otherwise be for a function type like (# #) -> Int).
-
-As a result, ReprArity is always strictly positive if Arity is. This is important
-because it allows us to distinguish at runtime between a thunk and a function
- takes a nullary unboxed tuple as an argument!
+We represent the nullary unboxed tuple as the unary (but void) type
+State# RealWorld.  The reason for this is that the ReprArity is never
+less than the Arity (as it would otherwise be for a function type like
+(# #) -> Int).
+
+As a result, ReprArity is always strictly positive if Arity is. This
+is important because it allows us to distinguish at runtime between a
+thunk and a function takes a nullary unboxed tuple as an argument!
 
 \begin{code}
 type UnaryType = Type