[GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux

[GHC]

#8276: Building Haddock documentation panics with perf build on x86_64 Linux
---------------------------------------+----------------------------------
        Reporter:  jstolarek           |            Owner:
            Type:  bug                 |           Status:  new
        Priority:  high                |        Milestone:
       Component:  Documentation       |          Version:  7.7
      Resolution:                      |         Keywords:
Operating System:  Unknown/Multiple    |     Architecture:  x86_64 (amd64)
 Type of failure:  Compile-time crash  |       Difficulty:  Unknown
       Test Case:                      |       Blocked By:
        Blocking:                      |  Related Tickets:
---------------------------------------+----------------------------------

Comment (by simonmar):

 Wow, we've got ourselves into a real mess here.  There's a lot that I
 don't understand about all this saving/restoring of static flags stuff,
 but I count at least three separate bugs.

 Bug 1: the Haddock panic that started this ticket.  Why is Haddock saving
 and restoring the static flag settings?  I can't even see how that would
 work, because we have CAFs that depend on the static flag settings (like
 `opt_PprStyle_debug`) and those can't be saved/restored.  But in any case,
 making the static flags empty is causing the panic in `staticFlags` to
 trigger.  I'm not clear on why we're calling `withGhc` twice in Haddock,
 and parsing all the flags twice etc.

 Bug 2:  When GHCi is dynamically linked and you load the `ghc` package,
 you are getting the same `ghc` package that GHCi itself is using, which is
 why the static flags are already set.  This is a serious problem, because
 it means that we can't have separate static flags when using the `ghc`
 package from GHCi.

 Bug 3: I also noticed `CoreMonad.reinitializeGlobals` while I was perusing
 the code.  That is needed when we're doing static linking (two `ghc`
 packages) but not when we're doing dynamic linking (one `ghc` package).
 Shouldn't there be some logic to test that somewhere?

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