1. 20 Dec, 2016 1 commit
  2. 19 Dec, 2016 1 commit
  3. 18 Dec, 2016 1 commit
  4. 09 Sep, 2016 1 commit
    • Alan Zimmerman's avatar
      Add hook for creating ghci external interpreter · 65d9597d
      Alan Zimmerman authored
      Summary:
      The external interpreter is launched by calling
      'System.Process.createProcess' with a 'CreateProcess' parameter.
      
      The current value for this has the 'std_in', 'std_out' and 'std_err'
      fields use the default of 'Inherit', meaning that the remote interpreter
      shares the stdio with the original ghc/ghci process.
      
      This patch introduces a new hook to the DynFlags, which has an
      opportunity to override the 'CreateProcess' fields, launch the process,
      and retrieve the stdio handles actually used.
      
      So if a ghci external interpreter session is launched from the GHC API
      the stdio can be redirected if required, which is useful for tooling/IDE
      integration.
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, simonmar, bgamari
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2518
      65d9597d
  5. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
  6. 17 Dec, 2015 1 commit
    • 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
  7. 06 Oct, 2015 1 commit
    • Edward Z. Yang's avatar
      Deduplicate one-shot/make compile paths. · 427f8a15
      Edward Z. Yang authored
      Summary:
      We had a duplicate copy of the code for --make and for -c
      which was a pain.  The call graph looked something like this:
      
          compileOne -> genericHscCompileGetFrontendResult -> genericHscFrontend
                                         hscCompileOneShot ---^
      
      with genericHscCompileGetFrontendResult and hscCompileOneShot
      duplicating logic for deciding whether or not recompilation
      was needed.
      
      This patchset fixes it, so now everything goes through this call-chain:
      
          compileOne (--make entry point)
              Calls hscIncrementCompile, invokes the pipeline to do codegen
              and sets up linkables.
          hscIncrementalCompile (-c entry point)
              Calls hscIncrementalFrontend, and then simplifying,
              desugaring, and writing out the interface.
          hscIncrementalFrontend
              Performs recompilation avoidance, if recompilation needed,
              does parses typechecking.
      
      I also cleaned up some of the MergeBoot nonsense by introducing
      a FrontendResult type.
      
      NB: this BREAKS #8101 again, because I can't unconditionally desugar
      due to Haddock barfing on lint, see #10600
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, simonmar, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1302
      427f8a15
  8. 10 Feb, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor the handling of quasi-quotes · f46360ed
      Simon Peyton Jones authored
      As Trac #10047 points out, a quasi-quotation [n|...blah...|] is supposed
      to behave exactly like $(n "...blah...").  But it doesn't!  This was outright
      wrong: quasiquotes were being run even inside brackets.
      
      Now that TH supports both typed and untyped splices, a quasi-quote is properly
      regarded as a particular syntax for an untyped splice. But apart from that
      they should be treated the same.  So this patch refactors the handling of
      quasiquotes to do just that.
      
      The changes touch quite a lot of files, but mostly in a routine way.
      The biggest changes by far are in RnSplice, and more minor changes in
      TcSplice.  These are the places where there was real work to be done.
      Everything else is routine knock-on changes.
      
      * No more QuasiQuote forms in declarations, expressions, types, etc.
        So we get rid of these data constructors
          * HsBinds.QuasiQuoteD
          * HsExpr.HsSpliceE
          * HsPat.QuasiQuotePat
          * HsType.HsQuasiQuoteTy
      
      * We get rid of the HsQuasiQuote type altogether
      
      * Instead, we augment the HsExpr.HsSplice type to have three
        consructors, for the three types of splice:
          * HsTypedSplice
          * HsUntypedSplice
          * HsQuasiQuote
        There are some related changes in the data types in HsExpr near HsSplice.
        Specifically: PendingRnSplice, PendingTcSplice, UntypedSpliceFlavour.
      
      * In Hooks, we combine rnQuasiQuoteHook and rnRnSpliceHook into one.
        A smaller, clearer interface.
      
      * We have to update the Haddock submodule, to accommodate the hsSyn changes
      f46360ed
  9. 20 Dec, 2014 1 commit
    • Luite Stegeman's avatar
      add runMeta hook · e7eef005
      Luite Stegeman authored
      Summary:
      The runMeta hook can be used to override how metaprogramming expressions
      are evaluated. It makes the metaprogramming request types explicit and
      has access to the TcM monad. This makes it a much more convenient starting
      point for implementing out of process Template Haskell than the existing
      hscCompileCoreExpr hook.
      
      Reviewers: hvr, edsko, austin, simonpj
      
      Reviewed By: austin
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D501
      e7eef005
  10. 15 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Fix dll-split problem with patch 'Make Core Lint check for locally-bound GlobalId' · 3f87866a
      Simon Peyton Jones authored
      The trouble was that my changes made a lot more files transitively link with
      DynFlags, which is the root module for the revolting Windows dll-split stuff.
      
      Anyway this patch fixes it, in a good way:
      
       - Make GHC/Hooks *not* import DsMonad, because DsMonad imports too
         much other stuff (notably tcLookup variants).  Really, Hooks depends
         only on *types* not *code*.
      
       - To do this I need the DsM type, and the types it depends on,
         not to be part of DsMonad.  So I moved it to TcRnTypes, which is
         where the similar pieces for the TcM and IfM monads live.
      
       - We can then delete DsMonad.hs-boot
      
       - There are a bunch of knock-on change, of no great significance
      3f87866a
  11. 03 Dec, 2014 1 commit
  12. 03 May, 2014 1 commit
  13. 08 Jan, 2014 1 commit
  14. 27 Dec, 2013 1 commit
    • Edsko de Vries's avatar
      Add hook for splicing in renamer · df2dd64d
      Edsko de Vries authored
      With the recent modifications to the TH infrastructure, many splices are now
      expanded in the renamer rather than the typechecker. This means that tools
      which inspect the renamed tree don't get to see the original splices. Added a
      new hook which gets called before such a splice gets expanded, analogous to the
      runQuasiQuoteHook.
      df2dd64d
  15. 22 Sep, 2013 1 commit