1. 15 Aug, 2019 1 commit
    • James Foster's avatar
      Remove unused imports of the form 'import foo ()' (Fixes #17065) · ca71d551
      James Foster authored
      These kinds of imports are necessary in some cases such as
      importing instances of typeclasses or intentionally creating
      dependencies in the build system, but '-Wunused-imports' can't
      detect when they are no longer needed. This commit removes the
      unused ones currently in the code base (not including test files
      or submodules), with the hope that doing so may increase
      parallelism in the build system by removing unnecessary
      dependencies.
      ca71d551
  2. 26 Jul, 2019 1 commit
  3. 07 Mar, 2019 1 commit
    • Phuong Trinh's avatar
      Fix #16392: revertCAFs in external interpreter when necessary · 7a68254a
      Phuong Trinh authored
      We revert CAFs when loading/adding modules in ghci (presumably to refresh
      execution states and to allow for object code to be unloaded from the runtime).
      However, with `-fexternal-interpreter` enabled, we are only doing it in the
      ghci process instead of the external interpreter process where the cafs are
      allocated and computed. This makes sure that revertCAFs is done in the
      appropriate process no matter if that flag is present or not.
      7a68254a
  4. 31 Jan, 2019 1 commit
  5. 27 Sep, 2018 1 commit
    • Simon Marlow's avatar
      Fix for recover with -fexternal-interpreter (#15418) · d00c3086
      Simon Marlow authored
      Summary:
      When using -fexternal-interpreter, recover was not treating a Q
      compuation that simply registered an error with addErrTc as failing.
      
      Test Plan:
      New unit tests:
      * T15418 is the repro from in the ticket
      * TH_recover_warns is a new test to ensure that we're keeping warnings when
        the body of recover succeeds.
      
      Reviewers: bgamari, RyanGlScott, angerman, goldfire, erikd
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15418
      
      Differential Revision: https://phabricator.haskell.org/D5185
      d00c3086
  6. 18 Sep, 2018 1 commit
  7. 16 Jul, 2018 1 commit
    • Simon Marlow's avatar
      Support the GHCi debugger with -fexternal-interpreter · 3bdf0d01
      Simon Marlow authored
      * All the tests in tests/ghci.debugger now pass with
        -fexternal-interpreter. These tests are now run with the ghci-ext way
        in addition to the normal way so we won't break it in the future.
      
      * I removed all the unsafeCoerce# calls from RtClosureInspect. Yay!
      
      The main changes are:
      
      * New messages: GetClosure and Seq.  GetClosure is a remote interface to
        GHC.Exts.Heap.getClosureData, which required Binary instances for
        various datatypes. Fortunately this wasn't too painful thanks to
        DeriveGeneric.
      
      * No cheating by unsafeCoercing values when printing them. Now we have
        to turn the Closure representation back into the native representation
        when printing Int, Float, Double, Integer and Char. Of these, Integer
        was the most painful - we now have a dependency on integer-gmp due to
        needing access to the representation.
      
      * Fixed a bug in rts/Heap.c - it was bogusly returning stack content as
        pointers for an AP_STACK closure.
      
      Test Plan:
      * `cd testsuite/tests/ghci.debugger && make`
      * validate
      
      Reviewers: bgamari, patrickdoc, nomeata, angerman, hvr, erikd, goldfire
      
      Subscribers: alpmestan, snowleopard, rwbarton, thomie, carter
      
      GHC Trac Issues: #13184
      
      Differential Revision: https://phabricator.haskell.org/D4955
      3bdf0d01
  8. 20 May, 2018 1 commit
    • patrickdoc's avatar
      Add HeapView functionality · ec22f7dd
      patrickdoc authored
      This pulls parts of Joachim Breitner's ghc-heap-view library inside GHC.
      The bits added are the C hooks into the RTS and a basic Haskell wrapper
      to these C hooks. The main reason for these to be added to GHC proper
      is that the code needs to be kept in sync with the closure types
      defined by the RTS. It is expected that the version of HeapView shipped
      with GHC will always work with that version of GHC and that extra
      functionality can be layered on top with a library like ghc-heap-view
      distributed via Hackage.
      
      Test Plan: validate
      
      Reviewers: simonmar, hvr, nomeata, austin, Phyx, bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: carter, patrickdoc, tmcgilchrist, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3055
      ec22f7dd
  9. 25 Mar, 2018 1 commit
    • Alec Theriault's avatar
      Support adding objects from TH · ceb91477
      Alec Theriault authored
      The user facing TH interface changes are:
      
        * 'addForeignFile' is renamed to 'addForeignSource'
        * 'qAddForeignFile'/'addForeignFile' now expect 'FilePath's
        * 'RawObject' is now a constructor for 'ForeignSrcLang'
        * 'qAddTempFile'/'addTempFile' let you request a temporary file
          from the compiler.
      
      Test Plan: unsure about this, added a TH test
      
      Reviewers: goldfire, bgamari, angerman
      
      Reviewed By: bgamari, angerman
      
      Subscribers: hsyl20, mboes, carter, simonmar, bitonic, ljli, rwbarton, thomie
      
      GHC Trac Issues: #14298
      
      Differential Revision: https://phabricator.haskell.org/D4217
      ceb91477
  10. 13 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Drop GHC 8.0 compatibility · 152055a1
      Ryan Scott authored
      GHC 8.4.1 is out, so now GHC's support window only extends
      back to GHC 8.2. This means we can delete gobs of code that were
      only used for GHC 8.0 support. Hooray!
      
      Test Plan: ./validate
      
      Reviewers: bgamari, erikd, dfeuer
      
      Reviewed By: bgamari, dfeuer
      
      Subscribers: alexbiehl, dfeuer, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4492
      152055a1
  11. 22 Sep, 2017 1 commit
    • Facundo Domínguez's avatar
      Implement TH addCorePlugin. · 17558690
      Facundo Domínguez authored
      This allows template-haskell code to add plugins to the compilation
      pipeline. Otherwise, the user would have to pass -fplugin=... to ghc.
      
      For now, plugin modules in the current package can't be used. This is
      because when TH runs, it is too late to let GHC know that the plugin
      modules needed to be compiled first.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari, austin, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: angerman, rwbarton, mboes, thomie
      
      GHC Trac Issues: #13608
      
      Differential Revision: https://phabricator.haskell.org/D3821
      17558690
  12. 01 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Drop GHC 7.10 compatibility · c13720c8
      Ryan Scott authored
      GHC 8.2.1 is out, so now GHC's support window only extends back to GHC
      8.0. This means we can delete gobs of code that was only used for GHC
      7.10 support. Hooray!
      
      Test Plan: ./validate
      
      Reviewers: hvr, bgamari, austin, goldfire, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: Phyx, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3781
      c13720c8
  13. 09 Mar, 2017 1 commit
    • bitonic's avatar
      Allow compilation of C/C++/ObjC/ObjC++ files with module from TH · 0fac488c
      bitonic authored
      The main goal is to easily allow the inline-c project (and
      similar projects such as inline-java) to emit C/C++ files to
      be compiled and linked with the current module.
      
      Moreover, `addCStub` is removed, since it's quite fragile. Most
      notably, the C stubs end up in the file generated by
      `CodeOutput.outputForeignStubs`, which is tuned towards
      generating a file for stubs coming from `capi` and Haskell-to-C
      exports.
      
      Reviewers: simonmar, austin, goldfire, facundominguez, dfeuer, bgamari
      
      Reviewed By: dfeuer, bgamari
      
      Subscribers: snowleopard, rwbarton, dfeuer, thomie, duncan, mboes
      
      Differential Revision: https://phabricator.haskell.org/D3280
      0fac488c
  14. 28 Feb, 2017 1 commit
    • Moritz Angermann's avatar
      Improve documentation for CreateBCOs Message. · aa2143e0
      Moritz Angermann authored
      After falling over the CreateBCOs message, and expecting it to contain
      ByteStrings encoding `ResolvedBCO`s instead of `[ResolvedBCO]`s, when
      deubbing issues with iserv, I'd like to extend the documentation here
      a bit, so the next one won't fall over it.
      
      Reviewers: simonmar, austin, rwbarton, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3234
      aa2143e0
  15. 18 Feb, 2017 1 commit
    • Ben Gamari's avatar
      Type-indexed Typeable · 8fa4bf9a
      Ben Gamari authored
      This at long last realizes the ideas for type-indexed Typeable discussed in A
      Reflection on Types (#11011). The general sketch of the project is described on
      the Wiki (Typeable/BenGamari). The general idea is that we are adding a type
      index to `TypeRep`,
      
          data TypeRep (a :: k)
      
      This index allows the typechecker to reason about the type represented by the `TypeRep`.
      This index representation mechanism is exposed as `Type.Reflection`, which also provides
      a number of patterns for inspecting `TypeRep`s,
      
      ```lang=haskell
      pattern TRFun :: forall k (fun :: k). ()
                    => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                              (arg :: TYPE r1) (res :: TYPE r2).
                       (k ~ Type, fun ~~ (arg -> res))
                    => TypeRep arg
                    -> TypeRep res
                    -> TypeRep fun
      
      pattern TRApp :: forall k2 (t :: k2). ()
                    => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b)
                    => TypeRep a -> TypeRep b -> TypeRep t
      
      -- | Pattern match on a type constructor.
      pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a
      
      -- | Pattern match on a type constructor including its instantiated kind
      -- variables.
      pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a
      ```
      
      In addition, we give the user access to the kind of a `TypeRep` (#10343),
      
          typeRepKind :: TypeRep (a :: k) -> TypeRep k
      
      Moreover, all of this plays nicely with 8.2's levity polymorphism, including the
      newly levity polymorphic (->) type constructor.
      
      Library changes
      ---------------
      
      The primary change here is the introduction of a Type.Reflection module to base.
      This module provides access to the new type-indexed TypeRep introduced in this
      patch. We also continue to provide the unindexed Data.Typeable interface, which
      is simply a type synonym for the existentially quantified SomeTypeRep,
      
          data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep
      
      Naturally, this change also touched Data.Dynamic, which can now export the
      Dynamic data constructor. Moreover, I removed a blanket reexport of
      Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable
      now).
      
      We also add a kind heterogeneous type equality type, (:~~:), to
      Data.Type.Equality.
      
      Implementation
      --------------
      
      The implementation strategy is described in Note [Grand plan for Typeable] in
      TcTypeable. None of it was difficult, but it did exercise a number of parts of
      the new levity polymorphism story which had not yet been exercised, which took
      some sorting out.
      
      The rough idea is that we augment the TyCon produced for each type constructor
      with information about the constructor's kind (which we call a KindRep). This
      allows us to reconstruct the monomorphic result kind of an particular
      instantiation of a type constructor given its kind arguments.
      
      Unfortunately all of this takes a fair amount of work to generate and send
      through the compilation pipeline. In particular, the KindReps can unfortunately
      get quite large. Moreover, the simplifier will float out various pieces of them,
      resulting in numerous top-level bindings. Consequently we mark the KindRep
      bindings as noinline, ensuring that the float-outs don't make it into the
      interface file. This is important since there is generally little benefit to
      inlining KindReps and they would otherwise strongly affect compiler performance.
      
      Performance
      -----------
      
      Initially I was hoping to also clear up the remaining holes in Typeable's
      coverage by adding support for both unboxed tuples (#12409) and unboxed sums
      (#13276). While the former was fairly straightforward, the latter ended up being
      quite difficult: while the implementation can support them easily, enabling this
      support causes thousands of Typeable bindings to be emitted to the GHC.Types as
      each arity-N sum tycon brings with it N promoted datacons, each of which has a
      KindRep whose size which itself scales with N. Doing this was simply too
      expensive to be practical; consequently I've disabled support for the time
      being.
      
      Even after disabling sums this change regresses compiler performance far more
      than I would like. In particular there are several testcases in the testsuite
      which consist mostly of types which regress by over 30% in compiler allocations.
      These include (considering the "bytes allocated" metric),
      
       * T1969:  +10%
       * T10858: +23%
       * T3294:  +19%
       * T5631:  +41%
       * T6048:  +23%
       * T9675:  +20%
       * T9872a: +5.2%
       * T9872d: +12%
       * T9233:  +10%
       * T10370: +34%
       * T12425: +30%
       * T12234: +16%
       * 13035:  +17%
       * T4029:  +6.1%
      
      I've spent quite some time chasing down the source of this regression and while
      I was able to make som improvements, I think this approach of generating
      Typeable bindings at time of type definition is doomed to give us unnecessarily
      large compile-time overhead.
      
      In the future I think we should consider moving some of all of the Typeable
      binding generation logic back to the solver (where it was prior to
      91c6b1f5). I've opened #13261 documenting this
      proposal.
      8fa4bf9a
  16. 09 Feb, 2017 1 commit
  17. 02 Feb, 2017 1 commit
    • Ben Gamari's avatar
      Add support for StaticPointers in GHCi · eedb3df0
      Ben Gamari authored
      Here we add support to GHCi for StaticPointers. This process begins by
      adding remote GHCi messages for adding entries to the static pointer
      table. We then collect binders needing SPT entries after linking and
      send the interpreter a message adding entries with the appropriate
      fingerprints.
      
      Test Plan: `make test TEST=StaticPtr`
      
      Reviewers: facundominguez, mboes, simonpj, simonmar, goldfire, austin,
      hvr, erikd
      
      Reviewed By: simonpj, simonmar
      
      Subscribers: RyanGlScott, simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2504
      
      GHC Trac Issues: #12356
      eedb3df0
  18. 20 Dec, 2016 1 commit
  19. 19 Dec, 2016 1 commit
  20. 18 Dec, 2016 1 commit
  21. 30 Aug, 2016 1 commit
    • mniip's avatar
      Tag pointers in interpreted constructors · a25bf267
      mniip authored
      Instead of stg_interp_constr_entry there are now 7 functions (one for
      each value of the tag bits) that tag the constructor pointer before
      returning. This is consistent with compiled constructors' entry code,
      and expectations that compiled code places on compiled constructors. The
      iserv protocol is extended with an extra field that explains what
      pointer tag the constructor should use.
      
      Test Plan: Added tests for #12523
      
      Reviewers: erikd, bgamari, hvr, austin, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: osa1, thomie, rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D2473
      
      GHC Trac Issues: #12523
      a25bf267
  22. 06 Jul, 2016 1 commit
    • Facundo Domínguez's avatar
      Have addModFinalizer expose the local type environment. · 567dbd9b
      Facundo Domínguez authored
      Summary:
      This annotates the splice point with 'HsSpliced ref e' where 'e' is the
      result of the splice. 'ref' is a reference that the typechecker will fill with
      the local type environment.
      
      The finalizer then reads the ref and uses the local type environment, which
      causes 'reify' to find local variables when run in the finalizer.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, simonmar, bgamari, austin, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: simonmar, thomie, mboes
      
      Differential Revision: https://phabricator.haskell.org/D2286
      
      GHC Trac Issues: #11832
      567dbd9b
  23. 24 Jun, 2016 2 commits
    • Simon Marlow's avatar
      Remote GHCi: comments only · eb732195
      Simon Marlow authored
      Summary: Add more Notes and signposts across the codebase to help navigation.
      
      Test Plan: validate
      
      Reviewers: goldfire, simonpj, austin, ezyang, hvr, bgamari, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2358
      eb732195
    • Simon Marlow's avatar
      Remote GHCi: separate out message types · bdb0d24b
      Simon Marlow authored
      Summary:
      From a suggestion by @goldfire: clean up the message types, so that
      rather than one Message type with all the messages, we have a separate
      THMessage type for messages sent back to GHC during TH execution.  At
      the same time I also removed the QDone/QFailed/QException messages
      into their own type, and made the result type of RunTH more accurate.
      
      Test Plan: validate
      
      Reviewers: goldfire, ezyang, austin, niteria, bgamari, erikd
      
      Subscribers: thomie, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D2356
      bdb0d24b
  24. 02 Feb, 2016 2 commits
    • Simon Marlow's avatar
      Remote GHCi: parallelise BCO serialization · c996db5b
      Simon Marlow authored
      Summary:
      Serialization of BCOs is slow, but we can parallelise it when using
      ghci -j<n>.  It parallelises nicely, saving multiple seconds off the
      link time in a large example I have.
      
      Test Plan:
      * validate
      * `ghci -fexternal-interpreter` in `nofib/real/anna`
      
      Reviewers: niteria, bgamari, ezyang, austin, hvr, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1877
      
      GHC Trac Issues: #11100
      c996db5b
    • Simon Marlow's avatar
      Remote GHCi: batch the creation of strings · 7cb1fae2
      Simon Marlow authored
      Summary:
      This makes a big performance difference especially when loading a
      large number of modules and using parallel compilation (ghci -jN).
      
      Test Plan:
      * validate
      * `ghci -fexternal-interpreter` in `nofib/real/anna`
      
      Reviewers: niteria, bgamari, ezyang, austin, hvr, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1876
      
      GHC Trac Issues: #11100
      7cb1fae2
  25. 27 Jan, 2016 1 commit
  26. 13 Jan, 2016 1 commit
  27. 08 Jan, 2016 3 commits
    • Ryan Scott's avatar
      Fix Template Haskell's handling of infix GADT constructors · 01634277
      Ryan Scott authored
      This is the second (and hopefully last) fix needed to make TH handle
      GADTs properly (after D1465). This Diff addresses some issues with infix
      GADT constructors, specifically:
      
      * Before, you could not determine if a GADT constructor was declared
        infix because TH did not give you the ability to determine if there is
        a //user-specified// fixity declaration for that constructor. The
        return type of `reifyFixity` was changed to `Maybe Fixity` so that it
        yields `Just` the fixity is there is a fixity declaration, and
        `Nothing` otherwise (indicating it has `defaultFixity`).
      * `DsMeta`/`Convert` were changed so that infix GADT constructors are
        turned into `GadtC`, not `InfixC` (which should be reserved for
        Haskell98 datatype declarations).
      * Some minor fixes to the TH pretty-printer so that infix GADT
        constructors will be parenthesized in GADT signatures.
      
      Fixes #11345.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari, jstolarek
      
      Reviewed By: jstolarek
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1744
      
      GHC Trac Issues: #11345
      01634277
    • Simon Marlow's avatar
      Support for qRecover in TH with -fexternal-interpreter · 09425cbe
      Simon Marlow authored
      Summary: This completes the support for TH with -fexternal-interpreter.
      
      Test Plan: validate
      
      Reviewers: bgamari, ezyang, austin, niteria, goldfire, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1748
      
      GHC Trac Issues: #11100
      09425cbe
    • Simon Marlow's avatar
      Enable stack traces with ghci -fexternal-interpreter -prof · 6be09e88
      Simon Marlow authored
      Summary:
      The main goal here is enable stack traces in GHCi.  After this change,
      if you start GHCi like this:
      
        ghci -fexternal-interpreter -prof
      
      (which requires packages to be built for profiling, but not GHC
      itself) then the interpreter manages cost-centre stacks during
      execution and can produce a stack trace on request.  Call locations
      are available for all interpreted code, and any compiled code that was
      built with the `-fprof-auto` familiy of flags.
      
      There are a couple of ways to get a stack trace:
      
      * `error`/`undefined` automatically get one attached
      * `Debug.Trace.traceStack` can be used anywhere, and prints the current
        stack
      
      Because the interpreter is running in a separate process, only the
      interpreted code is running in profiled mode and the compiler itself
      isn't slowed down by profiling.
      
      The GHCi debugger still doesn't work with -fexternal-interpreter,
      although this patch gets it a step closer.  Most of the functionality
      of breakpoints is implemented, but the runtime value introspection is
      still not supported.
      
      Along the way I also did some refactoring and added type arguments to
      the various remote pointer types in `GHCi.RemotePtr`, so there's
      better type safety and documentation in the bridge code between GHC
      and ghc-iserv.
      
      Test Plan: validate
      
      Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1747
      
      GHC Trac Issues: #11047, #11100
      6be09e88
  28. 22 Dec, 2015 1 commit
    • Ryan Scott's avatar
      Rework Template Haskell's handling of strictness · f975b0b1
      Ryan Scott authored
      Currently, Template Haskell's treatment of strictness is not enough to
      cover all possible combinations of unpackedness and strictness. In
      addition, it isn't equipped to deal with new features (such as
      `-XStrictData`) which can change a datatype's fields' strictness during
      compilation.
      
      To address this, I replaced TH's `Strict` datatype with
      `SourceUnpackedness` and `SourceStrictness` (which give the programmer a
      more complete toolkit to configure a datatype field's strictness than
      just `IsStrict`, `IsLazy`, and `Unpack`). I also added the ability to
      reify a constructor fields' strictness post-compilation through the
      `reifyConStrictness` function.
      
      Fixes #10697.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, bgamari, austin
      
      Reviewed By: goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1603
      
      GHC Trac Issues: #10697
      f975b0b1
  29. 21 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Maintain cost-centre stacks in the interpreter · c8c44fd9
      Simon Marlow authored
      Summary:
      Breakpoints become SCCs, so we have detailed call-stack info for
      interpreted code.  Currently this only works when GHC is compiled with
      -prof, but D1562 (Remote GHCi) removes this constraint so that in the
      future call stacks will be available without building your own GHCi.
      
      How can you get a stack trace?
      
      * programmatically: GHC.Stack.currentCallStack
      * I've added an experimental :where command that shows the stack when
        stopped at a breakpoint
      * `error` attaches a call stack automatically, although since calls to
        `error` are often lifted out to the top level, this is less useful
        than it might be (ImplicitParams still works though).
      * Later we might attach call stacks to all exceptions
      
      Other related changes in this diff:
      
      * I reduced the number of places that get ticks attached for
        breakpoints.  In particular there was a breakpoint around the whole
        declaration, which was often redundant because it bound no variables.
        This reduces clutter in the stack traces and speeds up compilation.
      
      * I tidied up some RealSrcSpan stuff in InteractiveUI, and made a few
        other small cleanups
      
      Test Plan: validate
      
      Reviewers: ezyang, bgamari, austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1595
      
      GHC Trac Issues: #11047
      c8c44fd9
  30. 17 Dec, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Random typo fixes · 3dd06d5e
      Herbert Valerio Riedel authored
      [skip ci]
      3dd06d5e
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      Summary:
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      
      (Some of this code is derived from GHCJS.)
      
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      -fexternal-interpreter.
      
      Reaosns we want this:
      
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
        entail.
      
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      
      Things that are not currently implemented for -fexternal-interpreter:
      
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1562
      4905b83a