Skip to content
Snippets Groups Projects
  1. Aug 30, 2016
    • 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
  2. Jul 22, 2016
  3. Jul 06, 2016
    • 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
  4. Jun 24, 2016
    • 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
  5. May 24, 2016
    • Ryan Scott's avatar
      Remove 'deriving Typeable' statements · 95dfdceb
      Ryan Scott authored
      Summary:
      Deriving `Typeable` has been a no-op since GHC 7.10, and now that we
      require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable`
      statements in GHC.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, hvr, bgamari
      
      Reviewed By: austin, hvr, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2260
      95dfdceb
  6. May 17, 2016
  7. May 12, 2016
  8. Apr 17, 2016
  9. Mar 08, 2016
  10. Feb 20, 2016
    • Simon Marlow's avatar
      Fix a double-free bug in -fexternal-interpreter · 23404857
      Simon Marlow authored
      Originally I planned to make this reference manually managed, but it
      looks like at some point I gave it a finalizer on the GHC side, but
      forgot to remove the manual free here.  The result is that ghc-iserv
      could crash in getStablePtr sometimes when using TH.
      23404857
  11. Feb 02, 2016
  12. Jan 27, 2016
  13. Jan 13, 2016
  14. Jan 12, 2016
  15. Jan 08, 2016
    • 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
  16. Jan 05, 2016
  17. Dec 31, 2015
  18. Dec 28, 2015
    • Herbert Valerio Riedel's avatar
      Synchronise ghci-package version with ghc-package · 01299ca8
      Herbert Valerio Riedel authored
      In order to simplify the task, the version munging logic has
      been radically simplified:
      
      Previously, in cases where the version contained dates as version components,
      the build-system would munge the version of the stage1 ghc package before
      registering the `ghc` package.
      
      However, this hack was already questionable at the time of its introduction
      (c.f. 7b45c46c).
      Simplifying the build-systems by avoiding such hacks may also help the
      shaking-up-ghc effort.
      
      So now we simply munge directly via the `.cabal` files, which gives a simpler
      picture, as now every stage is munged the same. Munging is only active when
      the first patch-level version component is a date. So stable snapshots and release
      candidates are unaffacted (as those have the date in the second patch-level
      version component)
      
      Reviewers: simonmar, bgamari, austin, thomie, ezyang
      
      Reviewed By: bgamari, thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D1673
      01299ca8
  19. Dec 27, 2015
  20. Dec 22, 2015
    • 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
  21. Dec 21, 2015
    • 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
  22. Dec 19, 2015
  23. Dec 18, 2015
  24. Dec 17, 2015
    • 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
Loading