[GHC] #14862: Switching to Cabal 2.2 makes ghc unusable

[GHC]

#14862: Switching to Cabal 2.2 makes ghc unusable
-------------------------------------+-------------------------------------
        Reporter:  alpmestan         |                Owner:  alpmestan
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:
       Component:  None              |              Version:  8.4.1-alpha3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by alpmestan):

 Alright, so gdb hasn't been all that helpful as it seems that single-
 stepping somehow makes me follow a codepath that just loops between the
 scheduler and the top of the haskell stack without really ever making
 progress. I have not managed to find a breakpoint that's "far enough" so
 that single-stepping would just lead me right to the crash.

 However, in the meantime hvr saw that:

 {{{#!hs
 import Data.Typeable

 data Foo = Foo deriving Eq
 data Bar = Bar deriving Eq
 main = print (Just Foo == cast Bar)
 }}}

 prints `True`, while it should obviously crash (because we'd expect `cast`
 to return `Nothing` here).

 What's more:

 {{{#!hs
 *Main Data.Typeable λ> typeRepFingerprint (typeRep (Proxy :: Proxy Foo))
 00000000000000000000000000000000
 *Main Data.Typeable λ> typeRepFingerprint (typeRep (Proxy :: Proxy Bar))
 00000000000000000000000000000000
 }}}

 hvr and I then looked at the code that generates those fingerprints. We
 end up calling `fingerprintFingerprints` for both, so I added a `print` to
 `fingerprintFingerprints` to see what the inputs to the fingerprinting
 code are in both cases. After digging some more for a while, we ended up
 realizing that `SIZEOF_STRUCT_MD5CONTEXT` is detected to be... 0! Which
 cause the md5 context & the digest to overlap in memory, and since we
 memset the md5 context to 0 at the end of the md5 computation in the C
 code, we end up with an all-0 digest, whatever the inputs!

 hvr has reported a fix in [https://phabricator.haskell.org/D4453#123717
 the aforementionned diff].

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