1. 18 Oct, 2016 7 commits
    • Ryan Scott's avatar
      Add test for #12411 · d84a824c
      Ryan Scott authored
      The fix for #12584 also fixed the problem in #12411. Let's add a test to ensure
      that it stays fixed.
      
      (cherry picked from commit 184d7cb8)
      d84a824c
    • Ryan Scott's avatar
      Fix Show derivation in the presence of RebindableSyntax/OverloadedStrings · d7a1f682
      Ryan Scott authored
      Summary:
      To fix this issue, we simply disable `RebindableSyntax` whenever we rename
      the code generated from a deriving clause.
      
      Fixes #12688.
      
      Test Plan: make test TEST=T12688
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2591
      
      GHC Trac Issues: #12688
      
      (cherry picked from commit b501709e)
      d7a1f682
    • Simon Peyton Jones's avatar
      Fix shadowing in mkWwBodies · 8ab454d9
      Simon Peyton Jones authored
      This bug, exposed by Trac #12562 was very obscure, and has been
      lurking for a long time.  What happened was that, in the
      worker/wrapper split
      
        a tyvar binder for a worker function
        accidentally shadowed an in-scope term variable
        that was mentioned in the body of the function
      
      It's jolly hard to provoke, so I have not even attempted to make
      a test case.  There's a Note [Freshen WW arguments] to explain.
      
      Interestingly, fixing the bug (which meant fresher type variables)
      revealed a second lurking bug: I'd failed to apply the substitution to
      the coercion in the second last case of mkWWArgs, which introduces a
      Cast.
      
      (cherry picked from commit 692c8df0)
      8ab454d9
    • Ryan Scott's avatar
      Add test for #12589 · 9467dfa8
      Ryan Scott authored
      Commit af21e388 fixed #12598. Let's add a test
      to make sure it stays fixed.
      
      (cherry picked from commit 042c5930)
      9467dfa8
    • Simon Peyton Jones's avatar
      Don't omit any evidence bindings · be94aebb
      Simon Peyton Jones authored
      This fixes Trac #12156, where we were omitting to make an
      evidence binding (because cec_suppress was on), but yet the
      program was compiled and run.
      
      The fix is easy, and involves deleting code :-).
      
      (cherry picked from commit af21e388)
      be94aebb
    • Simon Peyton Jones's avatar
      Fix wrapping order in matchExpectedConTy · bfaa770f
      Simon Peyton Jones authored
      The wrappers in matchExpectedConTy were being composed back
      to front, resulting in a Core Lint error.  Yikes!  This has
      been here a long time.
      
      Fixes Trac #12676.
      
      (cherry picked from commit f7278a90)
      bfaa770f
    • Simon Peyton Jones's avatar
      Correct order of existentials in pattern synonyms · 5c02b842
      Simon Peyton Jones authored
      Trac #12698 exposed a nasty bug in the typechecking for
      pattern synonmys: the existential type variables weren't
      being put in properly-scoped order.
      
      For some reason TcPatSyn.tcCollectEx was colleting them as a
      set, not as a list!  Easily fixed.
      
      (cherry picked from commit a693d1cb)
      5c02b842
  2. 14 Oct, 2016 4 commits
  3. 13 Oct, 2016 5 commits
    • Ryan Scott's avatar
      Add test for #12456 · 243994c3
      Ryan Scott authored
      Commit f352e5cd fixed #12456. Let's add a test
      to make sure it stays fixed.
      
      (cherry picked from commit fef1df4b)
      243994c3
    • Ben Gamari's avatar
      59741e4f
    • Simon Marlow's avatar
      Fix an assertion that could randomly fail · b7d6e20c
      Simon Marlow authored
      Summary:
      ASSERT_THREADED_CAPABILITY_INVARIANTS was testing properties of the
      returning_tasks queue, but that requires cap->lock to access safely.
      This assertion would randomly fail if stressed enough.
      
      Instead I've removed it from the catch-all
      ASSERT_PARTIAL_CAPABILITIY_INVARIANTS and made it a separate assertion
      only called under cap->lock.
      
      Test Plan:
      ```
      cd testsuite/tests/concurrent/should_run
      make TEST=setnumcapabilities001 WAY=threaded1 EXTRA_HC_OPTS=-with-rtsopts=-DS CLEANUP=0
      while true; do ./setnumcapabilities001.run/setnumcapabilities001 4 9 2000 || break; done
      ```
      
      Reviewers: niteria, bgamari, ezyang, austin, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2440
      
      GHC Trac Issues: #10860
      
      (cherry picked from commit ce13a9a9)
      b7d6e20c
    • Ben Gamari's avatar
      validate: Add --build-only · 5230fa04
      Ben Gamari authored
      This will allow us to split up Harbormaster output for the build and
      test stages of validation.
      
      Test Plan: `./validate --build-only && ./validate --testsuite-only`
      
      Reviewers: thomie, hvr, austin
      
      Differential Revision: https://phabricator.haskell.org/D2553
      
      (cherry picked from commit 4d2b15d5)
      5230fa04
    • Simon Peyton Jones's avatar
      Fix impredicativity (again) · c93ad554
      Simon Peyton Jones authored
      This patch fixes Trac #12616.
      
      Dignosis.  In TcUnify.tc_sub_type_ds we were going to some trouble to
      support co- and contra-variance even for impredicative types.  With
      -XImpredicativeTYpes, this allowed a unification variable to be
      unified with a polytype (probably wrongly) and that caused later
      trouble in the constraint solver, where -XImpredicativeTypes was /not/
      on.  In effect, -XImpredicativeTypes can't be switched on locally.
      
      Why did we want ImpredicativeTypes locally?  Because the program
      generated by GND for a higher-rank method involved impredicative
      instantation of 'coerce':
            op = coerce op   -- where op has a higher rank type
      See Note [Newtype-deriving instances] in TcGenDeriv.
      
      Cure.
      
      1.  It is ghastly to rely on ImpredicativeTypes (a 100% flaky
          feature) to instantiate coerce polymorphically.  Happily we
          now have Visible Type Application, so I've used that instead
          which should be solid and reliable.
      
      2.  I deleted the code in tc_sub_type_ds that allows the constraint
          solver to "look through" a unification variable to find a
          polytype.  That used to be essential in the days of ReturnTv,
          but it's utterly unreliable and should be consigned to the dustbin
          of history.  (We have ExpType now for the essential uses.)
      
      Tests involving ImpredicativeTypes are affected, but I'm not worried
      about them... it's advertised as a feature you can't rely on, and
      I want to reform it outright.
      
      (cherry picked from commit b612da66)
      c93ad554
  4. 12 Oct, 2016 3 commits
    • Simon Peyton Jones's avatar
      Some tiding up in TcGenDeriv · cec50665
      Simon Peyton Jones authored
      ..around newtype deriving instances.
      
      See esp the new Note [Newtype-deriving instances]
      
      No change in behaviour
      
      (cherry picked from commit 96d45145)
      cec50665
    • Simon Peyton Jones's avatar
      Add derived shadows only for Wanted constraints · fefc5301
      Simon Peyton Jones authored
      This patch implements choice (3) of comment:14 on Trac #12660.
      It cures an infinite loop (caused by the creation of an infinite
      type) in in compiling the 'singletons' package.
      
      See Note [Add derived shadows only for Wanteds] in TcSMonad.
      
      (cherry picked from commit 8fa5f5b1)
      fefc5301
    • Ben Gamari's avatar
      RnExpr: Actually fail if patterns found in expression · 47ae01bf
      Ben Gamari authored
      This fixes #12584, where wildcard patterns were snuck into an
      expression, which then crashed the typechecker in TcExpr since EWildPats
      aren't supposed to appear in the AST after renaming.
      
      The problem was that `rnTopSpliceDecl` failed to check for errors from
      `rnSplice` (as done by other callers to `rnSplice`).
      
      Thanks to Shayan for reporting this!
      
      Reviewers: simonpj, austin
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2539
      
      GHC Trac Issues: #12584
      
      (cherry picked from commit bce99086)
      47ae01bf
  5. 10 Oct, 2016 9 commits
  6. 09 Oct, 2016 1 commit
  7. 02 Oct, 2016 11 commits
    • Ben Gamari's avatar
      runghc: Fix import of System.Process on Windows · 9cc5a8f4
      Ben Gamari authored
      This apparently should have been an import of rawSystem instead of
      runProcess. Oops.
      
      Fixes D2538.
      
      Test Plan: Validate on Linux and Windows.
      
      Reviewers: austin, snowleopard
      
      Reviewed By: snowleopard
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2561
      
      (cherry picked from commit 8952cc3e)
      9cc5a8f4
    • snoyberg's avatar
      runghc: use executeFile to run ghc process on POSIX · c9042583
      snoyberg authored
      This means that, on POSIX systems, there will be only one ghc process
      used for running scripts, as opposed to the current situation of a
      runghc process and a ghc process. Beyond minor performance benefits of
      not having an extra fork and resident process, the more important impact
      of this is automatically getting proper signal handling. I noticed this
      problem myself when running runghc as PID1 inside a Docker container.
      
      I attempted to create a shim library for executeFile that would work for
      both POSIX and Windows, but unfortunately I ran into issues with exit
      codes being propagated correctly (see
      https://github.com/fpco/replace-process/issues/2). Therefore, this patch
      leaves the Windows behavior unchanged. Given that signals are a POSIX
      issue, this isn't too bad a trade-off. If someone has suggestions for
      better Windows _exec support, please let me know.
      
      Reviewers: erikd, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: Phyx, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2538
      
      (cherry picked from commit 42f1d867)
      c9042583
    • Ben Gamari's avatar
      Fix expected output for T7786 · a24092ff
      Ben Gamari authored
      I believe this is a benign difference between master and ghc-8.0.
      a24092ff
    • Nicolas Trangez's avatar
      Turn `__GLASGOW_HASKELL_LLVM__` into an integer again · 3b13a042
      Nicolas Trangez authored
      In GHC < 8.0.1, the value of `__GLASGOW_HASKELL_LLVM__`, exposed
      through the preprocessor when compiled with `-fllvm`, was an integer
      value, encoded according to some rules specified in the user guide.
      
      Due to an oversight, in GHC 8.0.1 the value of this define became a
      tuple, exposed as e.g. `(3, 7)`. This was an unintended regression.
      
      This patch turns the value of the `__GLASGOW_HASKELL_LLVM__` definition
      into a single integer again, but changes the formatting of said number
      slightly. Before, any LLVM version where the major or minor component >=
      10 would cause ambiguous values for `__GLASGOW_HASKELL_LLVM__`. With
      this patch, the value is in line with `__GLASGOW_HASKELL__`, adding a
      padding `0` in-between major and minor component if applicable (we
      assume no minors >= 100 will ever exist).
      
      The documentation in the user guide is updated accordingly, and a
      reference is made in the 8.0.2 release notes.
      
      Test Plan: validate
      
      Reviewers: bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2552
      
      GHC Trac Issues: #12628
      
      (cherry picked from commit b0d53a83)
      3b13a042
    • Ben Gamari's avatar
      Fix T12593 · 4557d944
      Ben Gamari authored
      (cherry picked from commit 779bcc90cf8a52270bcd70a82442d01d35d7c788)
      4557d944
    • Ben Gamari's avatar
      Fix T12512 · 15df5170
      Ben Gamari authored
      15df5170
    • Simon Peyton Jones's avatar
      Fix a bug in occurs checking · 836f0e24
      Simon Peyton Jones authored
      1. Trac #12593 exposed a long-standing bug in the occurs
         checking machinery.  When unifying two type variables
                a ~ b
         where a /= b, we were assuming that there could be
         no occurs-check error.  But there can: 'a' can occur
         in b's kind!  When the RHS was a non-tyvar we used
         occurCheckExpand, which /did/ look in kinds, but not
         when the RHS was a tyvar.
      
         This bug has been lurking ever since TypeInType, maybe
         longer.  And it was present both in TcUnify (the on-the-fly
         unifier), and in TcInteract.
      
         I ended up refactoring both so that the tyvar/tyvar
         path naturally goes through the same occurs-check as
         non-tyvar rhss.  It's simpler and more robust now.
      
         One good thing is that both unifiers now share
             TcType.swapOverVars
             TcType.canSolveByUnification
         previously they had different logic for the same goals
      
      2. Fixing this bug exposed another!  In T11635 we end
         up unifying
         (alpha :: forall k. k->*) ~ (beta :: forall k. k->*)
         Now that the occurs check is done for tyvars too, we
         look inside beta's kind.  And then reject the program
         becuase of the forall inside there.  But in fact that
         forall is fine -- it does not count as impredicative
         polymoprhism.   See Note [Checking for foralls]
         in TcType.
      
      3. All this fuss around occurrence checking forced me
         to look at TcUnify.checkTauTvUpdate
                and TcType.occurCheckExpand
         There's a lot of duplication there, and I managed
         to elminate quite a bit of it. For example,
         checkTauTvUpdate called a local 'defer_me'; and then
         called occurCheckExpand, which then used a very
         similar 'fast_check'.
      
         Things are better, but there is more to do.
      
      (cherry picked from commit 66a8c194)
      836f0e24
    • Simon Peyton Jones's avatar
      Kill off redundant SigTv check in occurCheckExpand · 11f9bffb
      Simon Peyton Jones authored
      This patch simply deletes code, the SigTv check in
      occurCheckExpand.  As the new comment says
      
      In the past we also rejected a SigTv matched with a non-tyvar
      But it is wrong to reject that for Givens;
      and SigTv is in any case handled separately by
         - TcUnify.checkTauTvUpdate (on-the-fly unifier)
         - TcInteract.canSolveByUnification (main constraint solver)
      
      (cherry picked from commit d25cb61a)
      11f9bffb
    • Ryan Scott's avatar
      Disallow standalone deriving declarations involving unboxed tuples or sums · c448d551
      Ryan Scott authored
      There was an awful leak where GHC permitted standalone `deriving`
      declarations to create instances for unboxed sum or tuple types. This
      fortifies the checks that GHC performs to catch this scenario and give
      an appropriate error message.
      
      Fixes #11509.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2557
      
      GHC Trac Issues: #11509
      
      (cherry picked from commit 23cf32da)
      c448d551
    • Simon Peyton Jones's avatar
      Print foralls in user format · 906ea044
      Simon Peyton Jones authored
      This fixes Trac #12597: in RnNames.warnMissingSignatures,
      use pprSigmaType not pprType
      
      (cherry picked from commit 796f0f2a)
      906ea044
    • Ömer Sinan Ağacan's avatar
      Fix layout of MultiWayIf expressions (#10807) · cb03d1cc
      Ömer Sinan Ağacan authored
      With this patch we stop generating virtual semicolons in MultiWayIf
      guards. Fixes #10807.
      
      Test Plan:
      
      Reviewers: simonmar, austin, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2524
      
      GHC Trac Issues: #10807
      
      (cherry picked from commit c36904d6)
      cb03d1cc