1. 16 May, 2016 1 commit
    • Ben Gamari's avatar
      Move Extension type to ghc-boot-th · eed820b6
      Ben Gamari authored
      This creates a new package, `ghc-boot-th`, to contain the `Extension`
      type, which now lives in `GHC.LanguageExtension.Type`. This ensures that
      the transitive dependency set of the `template-haskell` package remains
      minimal.
      
      The `GHC.LanguageExtensions.Type` module is also re-exported by
      `ghc-boot`, which provides an orphan `binary` instance as well.
      
      Test Plan: Validate
      
      Reviewers: goldfire, thomie, hvr, austin
      
      Reviewed By: thomie
      
      Subscribers: RyanGlScott, thomie, erikd, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D2224
      eed820b6
  2. 27 Jan, 2016 1 commit
    • Tamar Christina's avatar
      Enable RemoteGHCi on Windows · 44a5d51a
      Tamar Christina authored
      Makes the needed changes to make RemoteGHCi work on Windows.
      The approach passes OS Handles areound instead of the Posix Fd
      as on Linux.
      
      The reason is that I could not find any real documentation about
      the behaviour of Windows w.r.t inheritance and Posix FDs.
      
      The implementation with Fd did not seem to be able to find the Fd
      in the child process. Instead I'm using the much better documented
      approach of passing inheriting handles.
      
      This requires a small modification to the `process` library.
      https://github.com/haskell/process/pull/52
      
      Test Plan: ./validate On Windows x86_64
      
      Reviewers: thomie, erikd, bgamari, simonmar, austin, hvr
      
      Reviewed By: simonmar
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1836
      
      GHC Trac Issues: #11100
      44a5d51a
  3. 15 Jan, 2016 1 commit
  4. 28 Dec, 2015 1 commit
    • 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
  5. 19 Dec, 2015 1 commit
  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. 12 Dec, 2015 1 commit
    • Eric Seidel's avatar
      Rework the Implicit CallStack solver to handle local lets. · 3ec8288a
      Eric Seidel authored
      We can't just solve CallStack constraints indiscriminately when they
      occur in the RHS of a let-binder. The top-level given CallStack (if
      any) will not be in scope, so I've re-worked the CallStack solver as
      follows:
      
      1. CallStacks are treated like regular IPs unless one of the following
         two rules apply.
      
      2. In a function call, we push the call-site onto a NEW wanted
         CallStack, which GHC will solve as a regular IP (either directly from a
         given, or by quantifying over it in a local let).
      
      3. If, after the constraint solver is done, any wanted CallStacks
         remain, we default them to the empty CallStack. This rule exists mainly
         to clean up after rule 2 in a top-level binder with no given CallStack.
      
      In rule (2) we have to be careful to emit the new wanted with an
      IPOccOrigin instead of an OccurrenceOf origin, so rule (2) doesn't fire
      again. This is a bit shady but I've updated the Note to explain the
      trick.
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, hvr
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1422
      
      GHC Trac Issues: #10845
      3ec8288a
  8. 07 Dec, 2015 1 commit
  9. 02 Dec, 2015 1 commit
  10. 18 Nov, 2015 1 commit
  11. 29 Oct, 2015 1 commit
    • thomie's avatar
      Revert "Build system: don't create mk/are-validating.mk" · fa587316
      thomie authored
      Summary:
      This reverts commit aecf4a5f.
      
      It turns out the Simons are relying on 'mk/are-validating.mk', see
      D1307.
      
      The workflow they are using is:
        * run ./validate
        * find a bug in the compiler
        * try to fix the bug, running 'make 1' (or 'make 2') repeatedly. Because
          of 'mk/are-validating.mk', this uses the same build settings as validate.
        * continue ./validate (--no-clean)
      
      I suggested two alternatives:
      
        A. run 'make 1 Validating=YES' instead of 'make 1'
      
           Problem: when running `./validate --fast` or `./validate --hpc`
           instead of a normal `./validate`, validate sets ValidateSpeed and
           ValdateHpc in mk/are-validating.mk. You would for example have to run
           'make 1 Validating=YES ValidateSpeed=FAST' instead of 'make 1' to get the
           same build settings as `./validate --fast`, which is entirely too long and
           error prone.
      
        B. uncomment `#BuildFlavour=validate` in mk/build.mk, and include
           'mk/validate.mk'.
      
           Problems:
            * any other settings you have in build.mk will also get used.
            * the distinction between 'mk/validate.mk' and 'mk/build.mk' becomes less
              clear.
            * it is easy to forget to include 'mk/validate.mk'.
            * the build system again doesn't have access to the ValidateSpeed and
              ValdateHpc settings set by validate.
      
      Neither of these two options is entirely satisfactory.
      
      Reviewers: austin, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1383
      fa587316
  12. 23 Oct, 2015 1 commit
  13. 13 Oct, 2015 1 commit
    • Ryan Scott's avatar
      Make dataToQa aware of Data instances which use functions to implement toConstr · d2f9972a
      Ryan Scott authored
      Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function
      freak out if using a `Data` instance that produces a `Constr` (by means of
      `toConstr`) using a function name instead of a data constructor name. While
      such `Data` instances are somewhat questionable, they are nevertheless present
      in popular libraries (e.g., `containers`), so we can at least make `dataToQa`
      aware of their existence.
      
      In order to properly distinguish strings which represent variables (as opposed
      to data constructors), it was necessary to move functionality from `Lexeme` (in
      `ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named
      `bin-package-db`).
      
      Reviewed By: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1313
      
      GHC Trac Issues: #10796
      d2f9972a
  14. 09 Oct, 2015 2 commits
  15. 04 Oct, 2015 1 commit
  16. 03 Oct, 2015 1 commit
  17. 07 Apr, 2015 1 commit
  18. 13 Jan, 2015 1 commit
    • GregWeber's avatar
      add -th-file which generates a th.hs file · 07ace5c2
      GregWeber authored
      Summary:
      see Trac #8624
      
      similar functionality is now available
      with -ddump-to-file -ddump-splices
      
      However, users are already accustomed to -ddump-splices
      having a particular format, and this format is not completely valid code
      The goal of -th-file is to dump valid Haskell code
      
      Additionally, the convention of -ddump-to-file is to name the file after
      the flag, so the file is .dump-splices
      Given that the goal of the new flag is to generate valid Haskell,
      The extension should be .hs
      
      Additionally, -ddump-to-file effects all other dump flags
      
      Test Plan:
      look at the output of using the -th-file flag
      and compare it to the output of using -ddump-to-file and -ddump-splices
      I want to add test cases, but just need some pointers on getting started there
      
      Reviewers: thomie, goldfire, simonpj, austin
      
      Reviewed By: simonpj, austin
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D518
      
      GHC Trac Issues: #8624
      07ace5c2
  19. 27 Nov, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Embed Git commit id into `ghc --info` output · 73e5e2f8
      Herbert Valerio Riedel authored
      Since we switched to a Git submodule based GHC Git repo, `ghc.git`'s
      commit id uniquely identifies the state of the GHC source-tree. So
      having that information embedded into the `ghc` executable provides
      valuable information to track accurately (especially when created by
      buildbots) from which source-tree-state a given `ghc` snapshot
      (distribution) was generated.
      
      So this commit adds a new field `"Project Git commit id"` to the
      `ghc --info` meta-data containing the `./configure`-time Git commit id
      as reported by `git rev-parse HEAD`.
      
      This field can also be queried with `ghc --print-project-git-commit-id`.
      
      For source distributions, the file `GIT_COMMIT_ID` is created (with some
      sanity checking to detect stale commit ids, as that would render this
      information rather useless)
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D528
      73e5e2f8
  20. 07 Nov, 2014 1 commit
  21. 05 Oct, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Implement `MIN_VERSION_GLASGOW_HASKELL()` macro · 3549c952
      Herbert Valerio Riedel authored
      This exposes the `cProjectPatchLevel{1,2}` value at the CPP level to
      allow it to be used in CPP conditionals. Concretely, GHC 7.10.2.20150623
      would result in
      
        #define __GLASGOW_HASKELL__             710
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 2
        #define __GLASGOW_HASKELL_PATCHLEVEL2__ 20150623
      
      while GHC 7.10.3 results in
      
        #define __GLASGOW_HASKELL__             710
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 3
      
      and finally GHC 7.9.20141009 results in
      
        #define __GLASGOW_HASKELL__             709
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 20141009
      
      As it's error-prone to properly express CPP conditionals for testing GHC
      multi-component versions, a new macro `MIN_VERSION_GLASGOW_HASKELL()` is
      provided (also via the new CPP include file `ghcversion.h`)
      
      Finally, in order to make it easier to define the new CPP macro
      `MIN_VERSION_GLASGOW_HASKELL()`, a new default-included
      `include/ghcversion.h` is used for the new CPP definitions.
      
      Reviewed By: ekmett, austin, #ghc
      
      Differential Revision: https://phabricator.haskell.org/D66
      3549c952
  22. 28 Aug, 2014 1 commit
  23. 12 Jul, 2014 1 commit
  24. 04 Jul, 2014 1 commit
  25. 25 Jun, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Convert loose sub-repos into proper submodules (re #8545) · db19c665
      Herbert Valerio Riedel authored
      Specifically, the following sub-repos/modules are converted:
      
       - libffi-tarballs
       - libraries/array
       - libraries/deepseq
       - libraries/directory
       - libraries/dph
       - libraries/filepath
       - libraries/haskell2010
       - libraries/haskell98
       - libraries/hoopl
       - libraries/hpc
       - libraries/old-locale
       - libraries/old-time
       - libraries/parallel
       - libraries/process
       - libraries/stm
       - libraries/unix
       - nofib
       - utils/hsc2hs
      
      N.B. ghc-tarballs is not converted as it will probably be handled
           differently in the future.
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
      db19c665
  26. 09 May, 2014 1 commit
  27. 22 Apr, 2014 1 commit
  28. 23 Mar, 2014 1 commit
  29. 20 Feb, 2014 1 commit
  30. 14 Jan, 2014 1 commit
  31. 05 Aug, 2013 1 commit
  32. 09 Jun, 2013 1 commit
  33. 03 Feb, 2013 1 commit
  34. 02 Dec, 2012 1 commit
  35. 25 Nov, 2012 1 commit
  36. 29 Oct, 2012 3 commits
  37. 28 Oct, 2012 1 commit