[GHC] #12415: Fancy BinIface encoding for tuples is broken for constraint tuples

[GHC]

#12415: Fancy BinIface encoding for tuples is broken for constraint tuples
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #12357            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by bgamari:

@@ -5,4 +5,22 @@
- ffc21506894c7887d3620423aaf86bc6113a1071. The problem is very similar to
- the one which prevented us from encoding tuple type representations in
- #12357 (see ticket:12357#comment:31). By unwiring constraint tuples it
- becomes harder to identify them for special handling during serialization.
+ ffc21506894c7887d3620423aaf86bc6113a1071. Namely, `putName` now panics
+ when given a constraint tuple,
+ {{{#!hs
+ putTupleName_ :: BinHandle -> TyCon -> TupleSort -> Word32 -> IO ()
+ putTupleName_ bh tc tup_sort thing_tag
+   = -- ASSERT(arity < 2^(30 :: Int))
+     put_ bh (0x80000000 .|. (sort_tag `shiftL` 28) .|. (thing_tag `shiftL`
+ 26) .|. arity)
+   where
+     (sort_tag, arity) = case tup_sort of
+       BoxedTuple      -> (0, fromIntegral (tyConArity tc))
+       UnboxedTuple    -> (1, fromIntegral (tyConArity tc `div` 2))
+         -- See Note [Unboxed tuple RuntimeRep vars] in TyCon
+       ConstraintTuple -> pprPanic "putTupleName:ConstraintTuple" (ppr tc)
+ }}}
+ While this currently doesn't break anything, this is only because the
+ clever encoding isn't used for constraint tuples.
+
+ I believe the problem is very similar to the one which prevented us from
+ encoding tuple type representations in #12357 (see
+ ticket:12357#comment:31). By unwiring constraint tuples it becomes harder
+ to identify them for special handling during serialization.

New description:

 We have a special way of encoding tuple-related names in the interface
 file symbol table. See `Note [Symbol table representation of names]`.

 However, it was broken for constraint tuples by
 ffc21506894c7887d3620423aaf86bc6113a1071. Namely, `putName` now panics
 when given a constraint tuple,
 {{{#!hs
 putTupleName_ :: BinHandle -> TyCon -> TupleSort -> Word32 -> IO ()
 putTupleName_ bh tc tup_sort thing_tag
   = -- ASSERT(arity < 2^(30 :: Int))
     put_ bh (0x80000000 .|. (sort_tag `shiftL` 28) .|. (thing_tag `shiftL`
 26) .|. arity)
   where
     (sort_tag, arity) = case tup_sort of
       BoxedTuple      -> (0, fromIntegral (tyConArity tc))
       UnboxedTuple    -> (1, fromIntegral (tyConArity tc `div` 2))
         -- See Note [Unboxed tuple RuntimeRep vars] in TyCon
       ConstraintTuple -> pprPanic "putTupleName:ConstraintTuple" (ppr tc)
 }}}
 While this currently doesn't break anything, this is only because the
 clever encoding isn't used for constraint tuples.

 I believe the problem is very similar to the one which prevented us from
 encoding tuple type representations in #12357 (see
 ticket:12357#comment:31). By unwiring constraint tuples it becomes harder
 to identify them for special handling during serialization.

--

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