1. 16 Jan, 2019 1 commit
    • Alec Theriault's avatar
      Support printing `integer-simple` Integers in GHCi · 582a96f4
      Alec Theriault authored
      This means that `:p` no longer leaks the implementation details of
      `Integer` with `integer-simple`. The `print037` test case should
      exercise all possible code paths for GHCi's code around printing
      `Integer`s (both in `integer-simple` and `integer-gmp`).
      
      `ghc` the package now also has a Cabal `integer-simple` flag (like the
      `integer-gmp` one).
      582a96f4
  2. 14 Jan, 2019 1 commit
    • Herbert Valerio Riedel's avatar
      Update `Cabal` submodule · cb31b23d
      Herbert Valerio Riedel authored
      This also requires adapting `ghc-pkg` to use the new Cabal parsing API
      as the old ReadP-based one has finally been evicted for good.
      
      Hadrian bit finished by: Ben Gamari <ben@smart-cactus.org>
      cb31b23d
  3. 06 Jan, 2019 1 commit
    • Zejun Wu's avatar
      Fix bindist for ghci library · 3fb726d0
      Zejun Wu authored
      Summary:
      https://phabricator.haskell.org/D5169 built libghci for both vanilla way
      and profiling way. We need to include both in the bindist list so they
      will be installed.
      
      Test Plan:
      ```
      $ grep '^BuildFlavour' mk/build.mk
      BuildFlavour=perf
      $ make test_bindist
      $ grep HSghc-prim bindist-list.uniq
      ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.o
      ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.p_o
      ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3.a
      ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3-ghc8.7.20190101.so
      ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3_p.a
      ```
      3fb726d0
  4. 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
  5. 14 Jul, 2018 1 commit
  6. 08 Jun, 2018 1 commit
    • Moritz Angermann's avatar
      Move `iserv` into `utils` and change package name from `iserv-bin` to `iserv` · 6fbe5f27
      Moritz Angermann authored
      This is done for consistency. We usually call the package file the same name the
      folder has.  The move into `utils` is done so that we can move the library into
      `libraries/iserv` and the proxy into `utils/iserv-proxy` and then break the
      `iserv.cabal` apart.  This will make building the cross compiler with TH
      simpler, because we can build the library and proxy as separate packages.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, goldfire, erikd
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4436
      6fbe5f27
  7. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored
      Poor DPH and its vectoriser have long been languishing; sadly it seems there is
      little chance that the effort will be rekindled. Every few years we discuss
      what to do with this mass of code and at least once we have agreed that it
      should be archived on a branch and removed from `master`. Here we do just that,
      eliminating heaps of dead code in the process.
      
      Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
      `primitive` submodules.
      
      Test Plan: Validate
      
      Reviewers: simonpj, simonmar, hvr, goldfire, alanz
      
      Reviewed By: simonmar
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4761
      faee23bb
  8. 30 May, 2018 1 commit
    • Kavon Farvardin's avatar
      Extract hard-coded LLVM opt flags into a file · a4ae199c
      Kavon Farvardin authored
      To resolve ticket #11295, I think it makes sense to stop hard-coding
      the pass sequences used by GHC when compiling with LLVM into the
      compiler
      itself.
      
      This patchset introduces a companion to the existing `llvm-targets` file
      called `llvm-passes`. The passes file is a simple association list that
      holds the default LLVM `opt` pass sequence used by GHC. This allows end
      users to easily save their favorite optimization flags when compiling
      with LLVM.
      
      The main benefit for ticket #11295 is that when adding a custom pass
      sequence, it tends to be an extremely long string that would be
      unsightly in the code.
      
      This is essentially part 1 of 2 for ticket #11295.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, angerman
      
      Reviewed By: angerman
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4695
      a4ae199c
  9. 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
  10. 31 Mar, 2018 1 commit
    • Tamar Christina's avatar
      Remove MAX_PATH restrictions from RTS, I/O manager and various utilities · 4de585a5
      Tamar Christina authored
      Summary:
      This shims out fopen and sopen so that they use modern APIs under the hood
      along with namespaced paths.
      
      This lifts the MAX_PATH restrictions from Haskell programs and makes the new
      limit ~32k.
      
      There are only some slight caveats that have been documented.
      
      Some utilities have not been upgraded such as lndir, since all these things are
      different cabal packages I have been forced to copy the source in different places
      which is less than ideal. But it's the only way to keep sdist working.
      
      Test Plan: ./validate
      
      Reviewers: hvr, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #10822
      
      Differential Revision: https://phabricator.haskell.org/D4416
      4de585a5
  11. 20 Feb, 2018 1 commit
  12. 15 Feb, 2018 1 commit
    • Moritz Angermann's avatar
      Move `iserv` into `utils` and change package name from `iserv-bin` to `iserv` · 7c173b90
      Moritz Angermann authored
      This is done for consistency. We usually call the package file the same name the
      folder has.  The move into `utils` is done so that we can move the library into
      `libraries/iserv` and the proxy into `utils/iserv-proxy` and then break the
      `iserv.cabal` apart.  This will make building the cross compiler with TH
      simpler, because we can build the library and proxy as separate packages.
      
      Reviewers: bgamari, simonmar, goldfire, erikd
      
      Reviewed By: simonmar
      
      Subscribers: tdammers, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4377
      7c173b90
  13. 28 Nov, 2017 1 commit
  14. 18 Nov, 2017 1 commit
  15. 02 Nov, 2017 1 commit
  16. 27 Sep, 2017 1 commit
  17. 22 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Remove 'stm' from EXTRA_PACKAGES set · 5a8b8434
      Herbert Valerio Riedel authored
      This effectively broke `make sdist`; the surprising thing is that
      ./validate didn't catch this (and thus the buildbots didn't either).
      
      Also, I would have expected `EXTRA_PACKAGES` to be populated by the
      data in `./packages` which already encodes that information...
      
      This is a follow-up to 02ff7056
      5a8b8434
  18. 20 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Add 'stm' package to the global package database · 02ff7056
      Herbert Valerio Riedel authored
      This is a preparation for `haskeline` picking up a dependency on `stm`
      real soon now. See https://github.com/judah/haskeline/pull/61 for details.
      
      If we figure out a way to not bundle the libraries depended upon by the
      GHCi executable in the global package database (see #8919 for the original
      reason why we had to start bundling terminfo/haskeline in the first place)
      we can get rid of `stm` again...
      
      On the bright side, we were able to avoid uploading new `stm` releases for
      over two years already, so it shouldn't cause too much trouble if GHC imposes
      a strong preference on the `stm` package's version (this most likely will
      mostly affect Linux distributions & similiar).
      
      While at it, this also update the stm submodule to include relaxed
      bounds to allow the upcoming base-4.11 version.
      02ff7056
  19. 06 Sep, 2017 1 commit
    • Moritz Angermann's avatar
      Clean up opt and llc · 22733532
      Moritz Angermann authored
      The LLVM backend shells out to LLVMs `opt` and `llc` tools. This clean
      up introduces a shared data structure to carry the arguments we pass to
      each tool so that corresponding flags are next to each other. It drops
      the hard coded data layouts in favor of using `-mtriple` and have LLVM
      infer them. Furthermore we add `clang` as a proper tool, so we don't
      rely on assuming that `clang` is called `clang` on the `PATH` when using
      `clang` as the assembler.  Finally this diff also changes the type of
      `optLevel` from `Int` to `Word`, as we do not have negative optimization
      levels.
      
      Reviewers: erikd, hvr, austin, rwbarton, bgamari, kavon
      
      Reviewed By: kavon
      
      Subscribers: michalt, Ericson2314, ryantrinkle, dfeuer, carter, simonpj,
      kavon, simonmar, thomie, erikd, snowleopard
      
      Differential Revision: https://phabricator.haskell.org/D3352
      22733532
  20. 29 Aug, 2017 2 commits
    • Tamar Christina's avatar
      Add gen-dll as replacement for dll-split · 5f6a8204
      Tamar Christina authored
      Summary:
      This tool can be used to generate dll's for any list of object files
      given to it. It will then repartition them automatically to fit within
      a dll and generates as many dll's as needed to do this. Cyclic dependencies
      between these generated dlls are handle automatically so there is no need
      to tell it how to partition.
      
      It is also a lot more general than `dll-split` as it is able to split any
      package not just `libGHC`. It also uses a trick using GNU style import libraries
      to hide the splitting from the rest of the pipeline. Which means come linking time
      you don't need to know which dll contains what symbol or how many split dlls were
      created.
      
      The import libraries are by default created with libtool. However since libtool is BFD
      based it is very slow. So if present and detected by configure the `genlib` tool
      from the msys2 project is used. This makes a difference of about ~45 minutes when compiling.
      
      To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`.
      
      More detailed explaination of the process can be found here
      https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force
      
      GHC Trac Issues: #5987
      
      Differential Revision: https://phabricator.haskell.org/D3883
      5f6a8204
    • Tamar Christina's avatar
      Remove dll-split. · 5266ab90
      Tamar Christina authored
      This patch removes dll-split from the code base, the reason is dll-split
      no longer makes any sense. It was designed to split a dll in two, but we
      now already have many more symbols than would fit inside two dlls. So we
      need a third one. This means there's no point in having to maintain this
      list as it'll never work anyway and the solution isn't scalable.
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, #ghc_windows_task_force
      
      GHC Trac Issues: #5987
      
      Differential Revision: https://phabricator.haskell.org/D3882
      5266ab90
  21. 25 Aug, 2017 1 commit
  22. 22 Aug, 2017 1 commit
  23. 01 Aug, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Enable building Cabal with parsec · 36fe21aa
      Herbert Valerio Riedel authored
      Cabal's parser has been rewritten in terms of Parsec (which is not
      enabled yet in Cabal-2.0 by default, but can be enabled by a cabal
      flag). The plan for Cabal is to drop support for the non-parsec parser,
      so we need to prepare GHC to cope with new situation.
      
      However, this means that lib:Cabal requires three new library
      dependency submodules,
      
       - parsec
       - text
       - mtl
      
      What complicates matters is that we need to build `ghc-cabal` early on
      during the bootstrap phase which currently needs to invoke `ghc --make`
      directly. So these additional dependencies need to be integrated into
      the monolithic `ghc --make` invocation which produces the `ghc-cabal`
      executable.
      
      Test Plan: `./validate --fast` passed
      
      Reviewers: austin, bgamari
      
      Subscribers: erikd, phadej, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3757
      36fe21aa
  24. 21 Jul, 2017 1 commit
    • Ben Gamari's avatar
      build system: Ensure there are no duplicate files in bindist list · fefcbfa8
      Ben Gamari authored
      Several executables inexplicably appear twice in bindist.list, which
      ends up producing multiple tar file entries, consequently breaking BSD
      tar during extraction. I spent a fair amount of time trying to work out
      where these duplicates were coming from to no avail. Since Hadrian is
      right around the corner I'm satisfied with a terrible hack: just uniq
      bindist.list before producing the bindist tarball.
      
      Test Plan: Validate
      
      Reviewers: austin
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13979, #13974
      
      Differential Revision: https://phabricator.haskell.org/D3767
      fefcbfa8
  25. 23 Jun, 2017 1 commit
    • Michal Terepeta's avatar
      Hoopl: remove dependency on Hoopl package · 42eee6ea
      Michal Terepeta authored
      This copies the subset of Hoopl's functionality needed by GHC to
      `cmm/Hoopl` and removes the dependency on the Hoopl package.
      
      The main motivation for this change is the confusing/noisy interface
      between GHC and Hoopl:
      - Hoopl has `Label` which is GHC's `BlockId` but different than
        GHC's `CLabel`
      - Hoopl has `Unique` which is different than GHC's `Unique`
      - Hoopl has `Unique{Map,Set}` which are different than GHC's
        `Uniq{FM,Set}`
      - GHC has its own specialized copy of `Dataflow`, so `cmm/Hoopl` is
        needed just to filter the exposed functions (filter out some of the
        Hoopl's and add the GHC ones)
      With this change, we'll be able to simplify this significantly.
      It'll also be much easier to do invasive changes (Hoopl is a public
      package on Hackage with users that depend on the current behavior)
      
      This should introduce no changes in functionality - it merely
      copies the relevant code.
      Signed-off-by: Michal Terepeta's avatarMichal Terepeta <michal.terepeta@gmail.com>
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari, simonmar
      
      Reviewed By: bgamari, simonmar
      
      Subscribers: simonpj, kavon, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3616
      42eee6ea
  26. 02 Jun, 2017 1 commit
  27. 23 May, 2017 1 commit
    • Sergei Trofimovich's avatar
      ghc.mk: rename installed ghc-stage1 on non-windows · 10760105
      Sergei Trofimovich authored
      When user installs _native_ build ghc executable is renamed
      from '$(libexec)/bin/ghc-stage<N>' to '$(libexec)/bin/ghc'.
      But not on windows!
      
      In case of _cross-compiler_ rename should happen only
      for '$(libexec)/bin/ghc-stage<N>' runnable on non-windows
      platform.
      
      Before the change '$(libexec)/bin/ghc-stage<N>' rename happened
      for any compiler not targeting windows.
      
      After the patch rename also happens for '$(libexec)/bin/ghc-stage1'
      cross-compiler built for linux targeting windows (Stage1Only=YES case).
      
      Or on a concrete example:
      
         # host is x86_64-pc-linux-gnu
         $ ./configure --target=i686-w64-mingw32
         $ make install Stage1Only=YES
      
      Before the change the layout was:
         - '$(libexec)/bin/ghc-stage1' was installed
         - bin/ghc contained 'exec $(libexec)/bin/ghc' # missing file!
      After the change:
         - '$(libexec)/bin/ghc' was installed
         - bin/ghc contained 'exec $(libexec)/bin/ghc' # present file
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      10760105
  28. 22 May, 2017 1 commit
  29. 24 Apr, 2017 2 commits
  30. 23 Apr, 2017 1 commit
    • Sergei Trofimovich's avatar
      ghc.mk: fix 'make install' for cross-mingw32 · 74e5ec9e
      Sergei Trofimovich authored
      Attempt to install cross-compiled mingw32 GHC built on linux failed as:
      
          $ make install DESTDIR=$(pwd)/__i__
      
          "mv" "$(pwd)/__i__/usr/local/lib/ghc-8.3.20170422/bin/ghc-stage2" \
               "$(pwd)/__i__/usr/local/lib/ghc-8.3.20170422/bin/ghc"
          mv: failed to stat
               '$(pwd)/__i__/usr/local/lib/ghc-8.3.20170422/bin/ghc-stage2': \
               No such file or directory
      
      The rename should not be performed for windows targets.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      74e5ec9e
  31. 21 Apr, 2017 1 commit
  32. 08 Apr, 2017 1 commit
    • Sergei Trofimovich's avatar
      fix 'make install' for cross-stage2 · 54895c90
      Sergei Trofimovich authored
      When cross-built GHC is being installed one of
      latest steps is to register installed libraries
      with 'ghc-pkg'.
      
      GHC uses freshly installed 'ghc-pkg' and 'ghc-stage2'
      for that.
      
      Tested as:
          ./configure --target=aarch64-unknown-linux-gnu
          make install DESTDIR=$(pwd)/__s2 STRIP_CMD=:
      
      Before the change install failed on ghc-pkg execution phase:
      
          ".../ghc-cross/__s2/usr/local/lib/ghc-8.3.20170406/bin/ghc-pkg" \
              --force \
              --global-package-db \
              ".../ghc-cross/__s2/usr/local/lib/ghc-8.3.20170406/package.conf.d" \
              update rts/dist/package.conf.install
          /bin/sh: .../ghc-cross/__s2/usr/local/lib/ghc-8.3.20170406/bin/ghc-pkg: \
              No such file or directory
      
      To avoid breakage we use 'ghc' and 'ghc-pkg' built by stage0.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      
      Test Plan: run 'make install' on stage2 crosscompiler
      
      Reviewers: rwbarton, austin, bgamari
      
      Subscribers: thomie, snowleopard
      
      Differential Revision: https://phabricator.haskell.org/D3432
      54895c90
  33. 28 Feb, 2017 2 commits
  34. 26 Feb, 2017 2 commits
    • Ben Gamari's avatar
      build system: Persist CrossCompiling in binary distributions · a7eeb607
      Ben Gamari authored
      The build system uses the CrossCompiling variable to decide whether or
      not we should build various packages that must be built using the
      compiler.  Consequently, it is important that we persist its value in
      the binary distribution so we know during `make install` not to go
      looking for files that would have been built for these packages. Failing
      to do this causes #13325.
      
      Test Plan: Cross compile, `make binary-dist`, and try installing the
      binary distribution on the target
      
      Reviewers: hvr, austin, trofi, rwbarton
      
      Reviewed By: trofi, rwbarton
      
      Subscribers: carter, trofi, rwbarton, erikd, thomie, snowleopard, davean
      
      Differential Revision: https://phabricator.haskell.org/D3187
      a7eeb607
    • Edward Z. Yang's avatar
      Rename compact to ghc-compact. · a0b4a2ac
      Edward Z. Yang authored
      Summary:
      The plan is to release a separate library, 'compact', which gives a
      friendly user-facing interface.  This library is just enough so that we
      can make sure the functionality is working in GHC.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: bgamari, dfeuer, austin, simonmar, hvr
      
      Subscribers: thomie, erikd, snowleopard
      
      Differential Revision: https://phabricator.haskell.org/D3206
      a0b4a2ac
  35. 20 Dec, 2016 1 commit
  36. 19 Dec, 2016 1 commit