[GHC] #10436: Excessive numbers of packages loaded for TH

[GHC]

#10436: Excessive numbers of packages loaded for TH
-------------------------------------+-------------------------------------
              Reporter:  duncan      |             Owner:
                  Type:  bug         |            Status:  new
              Priority:  normal      |         Milestone:
             Component:  Compiler    |           Version:  7.10.1
              Keywords:              |  Operating System:  Unknown/Multiple
          Architecture:              |   Type of failure:  Compile-time
  Unknown/Multiple                   |  crash
             Test Case:              |        Blocked By:
              Blocking:              |   Related Tickets:
Differential Revisions:              |
-------------------------------------+-------------------------------------
 When using Template Haskell, the behaviour of ghc with regard to loading
 packages differs in these two cases:

 {{{
 ghc --make Blah.hs
 }}}
 vs
 {{{
 ghc --make Blah.hs -package foo
 }}}

 In the first case, ghc will work out for itself which packages it needs to
 load to run the TH code in `Blah.hs` while in the second case, ghc will
 unconditionally load package `foo` in addition to anything else.

 Why is this a problem? Consider a real example (reported on IRC):

 {{{
 ghc --make Main.hs
 [1 of 4] Compiling Uplink           ( Uplink.hs, Uplink.o )
 [2 of 4] Compiling FlightData       ( FlightData.hs, FlightData.o )
 Loading package ghc-prim ... linking ... done.
 Loading package integer-gmp ... linking ... done.
 Loading package base ... linking ... done.
 [3 of 4] Compiling Joystick         ( Joystick.hs, Joystick.o )
 [4 of 4] Compiling Main             ( Main.hs, Main.o )

 Linking Main.exe ...
 }}}

 This just loads `base` and its deps. Great, it works.

 Now the exact same `Main.hs` built by cabal (which of course uses
 `-package-id` flags):

 {{{
 cabal build
 Building jpl-0.1.0.0...
 Preprocessing executable 'jpl' for jpl-0.1.0.0...
 [1 of 4] Compiling Uplink           ( Uplink.hs, dist\build\jpl\jpl-
 tmp\Uplink.o )
 [2 of 4] Compiling FlightData       ( FlightData.hs, dist\build\jpl\jpl-
 tmp\FlightData.o )
 Loading package ghc-prim ... linking ... done.
 Loading package integer-gmp ... linking ... done.
 Loading package base ... linking ... done.
 Loading package array-0.5.0.0 ... linking ... done.
 Loading package deepseq-1.3.0.2 ... linking ... done.
 Loading package bytestring-0.10.4.0 ... linking ... done.
 Loading package containers-0.5.5.1 ... linking ... done.
 Loading package binary-0.7.1.0 ... linking ... done.
 Loading package SHA-1.6.4.2 ... linking ... done.
 Loading package text-1.2.0.4 ... linking ... done.
 }}}
 ... snip a further 80, '''yes 80 packages''' ...
 {{{
 Loading package linear-1.18.0.1 ... linking ... done.
 Loading package sdl2-2.0.0 ... linking ... ghc.exe: unable to load package
 `sdl2-2.0.0'
 ghc.exe: warning: WSACleanup from ws2_32 is linked instead of
 __imp_WSACleanup
 ghc.exe: warning: WSAStartup from ws2_32 is linked instead of
 __imp_WSAStartup
 ghc.exe: warning: WSACleanup from ws2_32 is linked instead of
 __imp_WSACleanup
 }}}
 ... snip more boring details of the linker errors ...

 So yes the problem is that in practice some packages (typically FFI
 things) just can't be loaded in GHCi/TH and then this scuppers everything
 else, despite the fact that these packages never needed to be loaded in
 the first place.

 So the feature request is this: always use the parsimonious demand-driven
 algorithm for deciding what packages to load when running TH snippets, and
 don't consider `-package` flags to be instructions to load these packages
 for running TH code.

 As a bonus it'll be quicker and our build output shorter.

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