1. 21 May, 2018 1 commit
  2. 21 Jan, 2018 1 commit
    • Oleg Grenrus's avatar
      Update Cabal submodule · 61db0b89
      Oleg Grenrus authored
      - Cabal-2.2 uses SPDX license identifiers, so I had to update
        `cabal-version: 2.1` packages `license: BSD3` to
        `license: BSD-3-Clause`
      - `ghc-cabal` used old ReadP parsec, now it uses `parsec` too
      - InstalledPackageInfo pretty-printing have changed a little,
        fields with default values aren't printed. This can be changed in
        `Cabal` still, but I haven't found problems with omitting them.
      
      Note: `BSD-3-Clause` is parsed as "name = BSD, version = 3" by old
      parser (because 3-Clause looks like version 3 with tag Clause).
      If you see *"BSD-3" is not a valid license*, then something is using
      old parser still.
      
      Fixes #9885.
      
      (cherry picked from commit 5d6e0806c690ac1958e4cbf609bc6b18048fb761)
      61db0b89
  3. 09 Nov, 2017 1 commit
    • Tamar Christina's avatar
      Update Win32 version for GHC 8.4. · bdd2d286
      Tamar Christina authored
      Update to Win32 2.6 which is the expected version release for 8.4
      
      This involves moving Cabal forward which brings some backwards incompatible
      changes that needs various fixups.
      
      Bump a bunch of submodules
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari, angerman
      
      Reviewed By: bgamari, angerman
      
      Subscribers: angerman, thomie, rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D4133
      bdd2d286
  4. 23 Jul, 2017 1 commit
  5. 23 Jun, 2017 1 commit
  6. 17 May, 2017 1 commit
    • Edward Z. Yang's avatar
      Fix #13703 by correctly using munged names in ghc-pkg. · d9e9a9b3
      Edward Z. Yang authored
      Summary:
      Cabal internal libraries are implemented using a trick, where the 'name'
      field in ghc-pkg registration file is munged into a new form to keep
      each internal library looking like a distinct package to ghc-pkg and
      other tools; e.g. the internal library q from package p is named
      z-p-z-q.
      
      Later, Cabal library got refactored so that we made a closer distinction
      between these "munged" package names and the true package name of a
      package.  Unfortunately, this is an example of a refactor for clarity in
      the source code which ends up causing problems downstream, because the
      point of "munging" the package name was to make it so that ghc-pkg and
      similar tools transparently used MungedPackageName whereever they
      previously used PackageName (in preparation for them learning proper
      syntax for package name + component name).  Failing to do this meant
      that internal libraries from the same package (but with different
      names) clobber each other.
      
      This commit search-replaces most occurrences of PackageName in
      ghc-pkg and turns them into MungedPackageName. Otherwise there
      shouldn't be any functional differenes.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: bgamari, austin
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13703
      
      Differential Revision: https://phabricator.haskell.org/D3590
      d9e9a9b3
  7. 20 Mar, 2017 1 commit
    • Edward Z. Yang's avatar
      Correctly account for -package-db ordering when picking packages. · e0eaea91
      Edward Z. Yang authored
      Summary:
      When I originally implemented ABI-based shadowing as per
      ee4e1654, I switched our strategy
      from pasting together lists to creating a map of all units first,
      and then selecting packages from this.  However, what I did
      not realize when doing this was that we actually depended
      on the *ordering* of these lists later, when we selected
      a preferred package to use.
      
      The crux is if I have -package-db db1 -package-db db2 -package p-0.1,
      and p-0.1 is provided by both db1 and db2, which one does the
      -package flag select?  Previously, this was undetermined; now
      we always select the instance from the LATEST package database.
      (If p-0.1 shows up multiple times in the same database, once again
      the chosen package is undefined.)
      
      The reason why cabal08 intermittently failed was that, in practice,
      we were sorting on the UnitId, so when we bumped version numbers,
      that often wibbled the UnitIds so that they compared oppositely.
      I've extended the test so that we check that the relation is
      antisymmetric.
      
      Fixes #13313Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: bgamari, austin
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3369
      e0eaea91
  8. 28 Feb, 2017 1 commit
  9. 26 Feb, 2017 2 commits
    • rwbarton's avatar
      tests: remove extra_files.py (#12223) · 3415bcaa
      rwbarton authored
      The script I used is included as testsuite/driver/kill_extra_files.py,
      though at this point it is for mostly historical interest.
      
      Some of the tests in libraries/hpc relied on extra_files.py, so this
      commit includes an update to that submodule.
      
      One test in libraries/process also relies on extra_files.py, but we
      cannot update that submodule so easily, so for now we special-case it
      in the test driver.
      3415bcaa
    • rwbarton's avatar
      tests: manually move some extra_files into *.T files · 98119f5a
      rwbarton authored
      Some of the *.T files were in libraries/hpc, so this contains an
      update to that submodule.
      98119f5a
  10. 22 Feb, 2017 2 commits
  11. 20 Feb, 2017 1 commit
  12. 22 Jan, 2017 1 commit
    • thomie's avatar
      Remove clean_cmd and extra_clean usage from .T files · 5d38fb69
      thomie authored
      The `clean_cmd` and `extra_clean` setup functions don't do anything.
      Remove them from .T files.
      
      Created using https://github.com/thomie/refactor-ghc-testsuite. This
      diff is a test for the .T-file parser/processor/pretty-printer in that
      repository.
      
          find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \;
      
      Tests containing inline comments or multiline strings are not modified.
      
      Preparation for #12223.
      
      Test Plan: Harbormaster
      
      Reviewers: austin, hvr, simonmar, mpickering, bgamari
      
      Reviewed By: mpickering
      
      Subscribers: mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3000
      
      GHC Trac Issues: #12223
      5d38fb69
  13. 21 Dec, 2016 1 commit
    • Edward Z. Yang's avatar
      Support for abi-depends for computing shadowing. · ee4e1654
      Edward Z. Yang authored
      Summary:
      This is a complete fix based off of
      ed7af26606b3a605a4511065ca1a43b1c0f3b51d for handling
      shadowing and out-of-order -package-db flags simultaneously.
      
      The general strategy is we first put all databases together,
      overriding packages as necessary.  Once this is done, we successfully
      prune out broken packages, including packages which depend on a package
      whose ABI differs from the ABI we need.
      
      Our check gracefully degrades in the absence of abi-depends, as
      we only check deps which are recorded in abi-depends.
      
      Contains time and Cabal submodule update.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: niteria, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2846
      
      GHC Trac Issues: #12485
      ee4e1654
  14. 15 Dec, 2016 1 commit
  15. 29 Nov, 2016 1 commit
    • Sylvain Henry's avatar
      Replace -fshow-source-paths with -fhide-source-paths · 3ec85630
      Sylvain Henry authored
      This patch reverts the change introduced with
      587dcccf and restores the previous
      default output of GHC (i.e., show source path and object path for each
      compiled module).
      
      The -fhide-source-paths flag can be used to hide these paths and reduce
      the line
      noise.
      
      Reviewers: gracjan, nomeata, austin, bgamari, simonmar, hvr
      
      Reviewed By: hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2728
      
      GHC Trac Issues: #12851
      3ec85630
  16. 12 Nov, 2016 1 commit
  17. 19 Oct, 2016 1 commit
  18. 08 Oct, 2016 2 commits
  19. 31 Aug, 2016 1 commit
  20. 29 Jun, 2016 1 commit
    • thomie's avatar
      Testsuite: use ignore_stderr/stdout instead of ignore_output · 1084d375
      thomie authored
      The problem with ignore_output is that it hides errors for WAY=ghci.
      GHCi always returns with exit code 0 (unless it is broken itself).
      
      For example: ghci015 must have been failing with compile errors for
      years, but we didn't notice because all output was ignored.
      
      Therefore, replace all uses of ignore_output with either ignore_stderr
      or ignore_stdout. In some cases I opted for adding the expected output.
      
      Update submodule hpc and stm.
      
      Reviewed by: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D2367
      1084d375
  21. 20 Jun, 2016 1 commit
    • thomie's avatar
      Testsuite: remove `-fforce-recomp` from default flags (#11980) · 3b49f8fa
      thomie authored
      There is no need for this flag anymore, since each test runs in a
      newly created directory. Removing it cleans up testlib.py a bit.
      
      There is a small risk that this renders some tests useless. It's hard to
      know. Those tests should have specified -fforce-recomp` explicitly
      anyway, so I'm not going to worry about it. I've fixed the ones that
      failed without -fforce-recomp.
      
      Reviewed by: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D2346
      3b49f8fa
  22. 07 Jun, 2016 1 commit
  23. 30 Apr, 2016 1 commit
  24. 29 Feb, 2016 1 commit
  25. 25 Feb, 2016 1 commit
  26. 23 Feb, 2016 1 commit
  27. 21 Feb, 2016 1 commit
  28. 10 Feb, 2016 1 commit
    • Edward Z. Yang's avatar
      Error early when you register with too old a version of Cabal. · d80caca1
      Edward Z. Yang authored
      On the GHC 8.0 RCs, multiple users reported a very strange error
      whereby GHC would complain that the symbols names recorded in interface
      files did not match the expected name.  The reason for this is
      that they were using an old version of Cabal which chose symbol
      names differently from the installed package ID ('id' field) which
      the package was to be installed with; GHC 8.0 now mandates that
      these coincides.
      
      This change adds a test to ghc-pkg to make sure that 'id' and 'key'
      (which is how Cabal previously reported what the symbol name
      was supposed to be) match; if they don't match or key is missing,
      we assume that the Cabal was too old.
      
      Bikeshed points:
      
          - Should we offer more information about how to upgrade
            Cabal correctly (i.e. specify a version?)
      
          - Should we allow for a missing 'key'?  If we allow for
            'key' to be missing, we lose the ability to detect
            Cabal from GHC 7.8 or earlier being used.  If we
            require it to be specified, then it will not be possible
            for Cabal to deprecate the (unused) field and remove it
            without having BC for 8.0.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, bgamari, hvr
      
      Reviewed By: hvr
      
      Subscribers: bergmark, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1892
      
      GHC Trac Issues: #11558
      d80caca1
  29. 29 Dec, 2015 1 commit
  30. 27 Dec, 2015 1 commit
    • Edward Z. Yang's avatar
      The -package flag should select match from right-most package db. · 1b000168
      Edward Z. Yang authored
      The shadowing and default behavior (in the absence of
      -hide-all-packages) prefers packages that come from "later" package
      databases.  So for example if tmp1.d and tmp2.d both expose p-1.0, then
      
          ghc -package-db tmp1.d -package-db tmp2.d
      
      brings the p-1.0 from tmp2.d into scope (and if they have the same IPID,
      tmp2.d shadows tmp1.d).  HOWEVER, -package flags do NOT respect this
      behavior.
      
          ghc -package-db tmp1.d -package-db tmp2.d -package p-1.0
      
      this will force the p-1.0 from tmp1.d to be exposed!  This is
      confusing, so this patch makes the behavior of -package flags
      consistent.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1709
      1b000168
  31. 21 Dec, 2015 1 commit
  32. 18 Dec, 2015 1 commit
  33. 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
  34. 11 Dec, 2015 1 commit
  35. 29 Nov, 2015 1 commit
  36. 07 Nov, 2015 1 commit
    • Simon Marlow's avatar
      Make GHCi & TH work when the compiler is built with -prof · ce1f1607
      Simon Marlow authored
      Summary:
      Amazingly, there were zero changes to the byte code generator and very
      few changes to the interpreter - mainly because we've used good
      abstractions that hide the differences between profiling and
      non-profiling.  So that bit was pleasantly straightforward, but there
      were a pile of other wibbles to get the whole test suite through.
      
      Note that a compiler built with -prof is now like one built with
      -dynamic, in that to use TH you have to build the code the same way.
      For dynamic, we automatically enable -dynamic-too when TH is required,
      but we don't have anything equivalent for profiling, so you have to
      explicitly use -prof when building code that uses TH with a profiled
      compiler.  For this reason Cabal won't work with TH.  We don't expect
      to ship a profiled compiler, so I think that's OK.
      
      Test Plan: validate with GhcProfiled=YES in validate.mk
      
      Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1407
      
      GHC Trac Issues: #4837, #545
      ce1f1607
  37. 01 Nov, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Bump `base` version to 4.9.0.0 (closes #11026) · f8ba4b55
      Herbert Valerio Riedel authored
      This also relaxes a few upper bounds on base in the ghc.git repo;
      
      This required a mass-rewrite in testsuite/
      
        sed -i s,base-4.8.2.0,base-4.9.0.0,g $(git grep -Fl 'base-4.8.2.0')
      
      because it turns out the testsuite is still sensitive to package version
      changes.
      f8ba4b55