1. 21 May, 2018 1 commit
  2. 20 May, 2018 2 commits
    • Simon Marlow's avatar
      storageAddCapabilities: fix bug in updating nursery pointers · 31d38067
      Simon Marlow authored
      Summary:
      We were unconditionally updating the nursery pointers to be
      `nurseries[cap->no]`, but when using nursery chunks this might be
      wrong. This manifested as a later assertion failure in allocate().
      
      Test Plan: new test case
      
      Reviewers: bgamari, niteria, erikd
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4649
      
      (cherry picked from commit 4cb5595e)
      31d38067
    • Ömer Sinan Ağacan's avatar
      Fix #15038 · 64ecfc37
      Ömer Sinan Ağacan authored
      We introduce a new Id for unused pointer values in unboxed sums that is
      not CAFFY. Because the Id is not CAFFY it doesn't make non-CAFFY
      definitions CAFFY, fixing #15038.
      
      To make sure anything referenced by the new id will be retained we get a
      stable pointer to in on RTS startup.
      
      Test Plan: Passes validate
      
      Reviewers: simonmar, simonpj, hvr, bgamari, erikd
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15038
      
      Differential Revision: https://phabricator.haskell.org/D4680
      
      (cherry picked from commit b2ff5dde)
      64ecfc37
  3. 14 Apr, 2018 3 commits
    • Simon Peyton Jones's avatar
      SpecConstr: accommodate casts in value arguments · 6ed694d7
      Simon Peyton Jones authored
      This commit:
      
        commit fb050a33
        Author: Simon Peyton Jones <simonpj@microsoft.com>
        Date:   Thu Oct 12 11:00:19 2017 +0100
      
        Do not bind coercion variables in SpecConstr rules
      
      arranged to reject any SpecConstr call pattern that mentioned
      a coercion in the pattern.
      
      There was a good reason for that
      -- see Note [SpecConstr and casts] --
      but I didn't realise how important it was to accept patterns
      that mention casts in /terms/.  Trac #14936 showed this up.
      
      This patch just narrows the restriction to discard only
      the cases where the coercion is mentioned only in types.
      Fortunately that was pretty easy to do.
      
      (cherry picked from commit 5ab8094e)
      6ed694d7
    • Joachim Breitner's avatar
      Add test case for #15005 · e1071f6e
      Joachim Breitner authored
      this succeeds on `master` right now, but I confirmed that it fails on
      ghc-8.4.1-release.
      
      (cherry picked from commit 3f59d380)
      e1071f6e
    • Joachim Breitner's avatar
      CSE: Walk past join point lambdas (#15002) · 4edcef78
      Joachim Breitner authored
      As the CSE transformation traverses the syntax tree, it needs to go past
      the lambdas of a join point, and only look for CSE opportunities inside,
      as a join point’s lambdas must be preserved. Simple fix; comes with a
      Note and a test case.
      
      Thanks to Ryan Scott for an excellently minimized test case, and for
      bisecting GHC.
      
      Differential Revision: https://phabricator.haskell.org/D4572
      
      (cherry picked from commit ae0cff0a)
      4edcef78
  4. 13 Apr, 2018 2 commits
    • Ryan Scott's avatar
      Bump version numbers: base-4.11.1.0, integer-gmp-1.0.2.0 · b4012b61
      Ryan Scott authored
      This takes care of bumping the `base` and `integer-gmp`
      minor version numbers in anticipation of a GHC 8.4.2 release.
      
      While I was in town, I also filled in a `@since TODO` Haddock
      annotation for `powModSecInteger` in `integer-gmp` with
      `1.0.2.0`, and updated the changelog accordingly.
      
      Test Plan: ./validate
      
      Reviewers: hvr, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15025
      
      Differential Revision: https://phabricator.haskell.org/D4586
      
      (cherry picked from commit c4814ab6)
      b4012b61
    • Ryan Scott's avatar
      Fix #9438 by converting a panic to an error message · 20f6dae0
      Ryan Scott authored
      Previously, GHC was quite eager to panic whenever it was fed
      an archive file when `DYNAMIC_GHC_PROGRAMS=YES`. This ought to be an
      explicit error message instead, so this patch accomplishes just that.
      
      Test Plan: make test TEST=T14708
      
      Reviewers: Phyx, hvr, bgamari
      
      Reviewed By: Phyx
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #9438, #14708, #15032
      
      Differential Revision: https://phabricator.haskell.org/D4589
      
      (cherry picked from commit 7613a812)
      20f6dae0
  5. 29 Mar, 2018 3 commits
    • Ryan Scott's avatar
      Don't permit data types with return kind Constraint · b5c50241
      Ryan Scott authored
      Previously, GHC allowed all of the following:
      
      ```lang=haskell
      data Foo1 :: Constraint
      data family Foo2 :: Constraint
      data family Foo3 :: k
      data instance Foo3 :: Constraint
      ```
      
      Yikes! This is because GHC was confusing `Type` with `Constraint`
      due to careless use of the `isLiftedTypeKind` function. To respect
      this distinction, I swapped `isLiftedTypeKind` out for
      `tcIsStarKind`—which does respect this distinction—in the right
      places.
      
      Test Plan: make test TEST="T14048a T14048b T14048c"
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, carter
      
      GHC Trac Issues: #14048
      
      Differential Revision: https://phabricator.haskell.org/D4479
      
      (cherry picked from commit f748c529)
      b5c50241
    • Simon Peyton Jones's avatar
      Fix tcDataKindSig · 02aa02f1
      Simon Peyton Jones authored
      This patch fixes an outright bug in tcDataKindSig, shown up in Trac
      of a data type declaration.  See Note [TyConBinders for the result kind
      signature of a data type]
      
      I also took the opportunity to elminate the DataKindCheck argument
      and data type from tcDataKindSig, instead moving the check to the
      call site, which is easier to understand.
      
      (cherry picked from commit 68149452)
      02aa02f1
    • Ömer Sinan Ağacan's avatar
      Revert "GHCi: Don't remove shadowed bindings from typechecker scope." · fbc4ebaf
      Ömer Sinan Ağacan authored
      This reverts commit 59d7ee53 and enables
      the test for #14052.
      
      (See #14052 for the discussion)
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14052
      
      Differential Revision: https://phabricator.haskell.org/D4478
      
      (cherry picked from commit 98c7749c)
      fbc4ebaf
  6. 26 Mar, 2018 9 commits
    • Simon Peyton Jones's avatar
      Fix a nasty bug in the pure unifier · 1132ec68
      Simon Peyton Jones authored
      The pure unifier was building an infinite type, through a defective
      occurs check.  So GHC went into an infinite loop.
      
      Reason: we were neglecting the 'kco' part of the type, which
      'unify_ty' maintains.  Yikes.
      
      The fix is easy.  I refactored a bit to make it harder to
      go wrong in future.
      
      (cherry picked from commit e99fdf77)
      1132ec68
    • Ryan Scott's avatar
      Fix two pernicious bugs in DeriveAnyClass · d8dbe293
      Ryan Scott authored
      The way GHC was handling `DeriveAnyClass` was subtly wrong
      in two notable ways:
      
      * In `inferConstraintsDAC`, we were //always// bumping the `TcLevel`
        of newly created unification variables, under the assumption that
        we would always place those unification variables inside an
        implication constraint. But #14932 showed precisely the scenario
        where we had `DeriveAnyClass` //without// any of the generated
        constraints being used inside an implication, which made GHC
        incorrectly believe the unification variables were untouchable.
      * Even worse, we were using the generated unification variables from
        `inferConstraintsDAC` in every single iteration of `simplifyDeriv`.
        In #14933, however, we have a scenario where we fill in a
        unification variable with a skolem in one iteration, discard it,
        proceed on to another iteration, use the same unification variable
        (still filled in with the old skolem), and try to unify it with
        a //new// skolem! This results in an utter disaster.
      
      The root of both these problems is `inferConstraintsDAC`. This patch
      fixes the issue by no longer generating unification variables
      directly in `inferConstraintsDAC`. Instead, we store the original
      variables from a generic default type signature in `to_metas`, a new
      field of `ThetaOrigin`, and in each iteration of `simplifyDeriv`, we
      generate fresh meta tyvars (avoiding the second issue). Moreover,
      this allows us to more carefully fine-tune the `TcLevel` under which
      we create these meta tyvars, fixing the first issue.
      
      Test Plan: make test TEST="T14932 T14933"
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14932, #14933
      
      Differential Revision: https://phabricator.haskell.org/D4507
      
      (cherry picked from commit 98930426)
      d8dbe293
    • Tao He's avatar
      UnboxedTuples can't be used as constraints · 43f63a6b
      Tao He authored
      Fixes #14740.
      
      Test Plan: make test TEST="14740"
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14740
      
      Differential Revision: https://phabricator.haskell.org/D4359
      
      (cherry picked from commit ced9fbd3)
      43f63a6b
    • Ryan Scott's avatar
      Fix #14934 by including axSub0R in typeNatCoAxiomRules · e04aaf75
      Ryan Scott authored
      For some reason, `axSub0R` was left out of `typeNatCoAxiomRules` in
      `TcTypeNats`, which led to disaster when trying to look up `Sub0R` from
      an interface file, as demonstrated in #14934.
      
      The fix is simple—just add `axSub0R` to that list. To help prevent
      an issue like this happening in the future, I added a
      `Note [Adding built-in type families]` to `TcTypeNats`, which
      contains a walkthrough of all the definitions in `TcTypeNats` you
      need to update when adding a new built-in type family.
      
      Test Plan: make test TEST=T14934
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14934
      
      Differential Revision: https://phabricator.haskell.org/D4508
      
      (cherry picked from commit c3aea396)
      e04aaf75
    • Simon Peyton Jones's avatar
      Fix seq# case of exprOkForSpeculation · ac1ade1a
      Simon Peyton Jones authored
      This subtle patch fixes Trac #5129 (again; comment:20
      and following).
      
      I took the opportunity to document seq# properly; see
      Note [seq# magic] in PrelRules, and Note [seq# and expr_ok]
      in CoreUtils.
      
      (cherry picked from commit abaf43d9)
      ac1ade1a
    • Simon Peyton Jones's avatar
      Fix over-eager constant folding in bitInteger · 3c6a0578
      Simon Peyton Jones authored
      The RULE for bitInteger was trying to constant-fold
      
          bitInteger 9223372036854775807#
      
      which meant constructing a gigantic Integer at compile
      time.  Very bad idea!  Easily fixed.
      
      Fixes Trac #14959, #14962.
      
      (cherry picked from commit efc844f5)
      3c6a0578
    • Ömer Sinan Ağacan's avatar
      Slighly improve infix con app pattern errors · 161467c1
      Ömer Sinan Ağacan authored
      Given this program:
      
          main = do
            f $ do
              a <- return 3
                c <- do
                return 5
      
      GHC previously gave this error message:
      
          Main.hs:2:7: error:
              Parse error in pattern: do a <- return 3 c
              Possibly caused by a missing 'do'?
            |
          2 |   f $ do
            |       ^^...
      
      What happened is GHC considered the whole `f $ do a <- return 3 c` as a
      pattern. When parsed as an expression it becomes an infix application of
      `($)`, and GHC checks left and right hand sides before checking if `($)`
      is a valid infix constructor name, and shows the first error it got.
      
      If instead we first check if the infix op is valid in pattern context,
      the error message becomes much clearer:
      
          Main.hs:2:3: error:
              Parse error in pattern: f $ do a <- return 3 c
              Possibly caused by a missing 'do'?
            |
          2 |   f $ do
            |   ^^^^^^...
      
      This may not entirely fix #11188 but I think it's an improvement.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #11188
      
      Differential Revision: https://phabricator.haskell.org/D4497
      
      (cherry picked from commit cb6d8589)
      161467c1
    • Ryan Scott's avatar
      Fix #14916 with an additional validity check in deriveTyData · 1887441a
      Ryan Scott authored
      Manually-written instances and standalone-derived instances
      have the benefit of having the `checkValidInstHead` function run over
      them, which catches manual instances of built-in types like `(~)` and
      `Coercible`. However, instances generated from `deriving` clauses
      weren't being passed through `checkValidInstHead`, leading to
      confusing results as in #14916.
      
      `checkValidInstHead` also has additional validity checks for language
      extensions like `FlexibleInstances` and `MultiParamTypeClasses`. Up
      until now, GHC has never required these language extensions for
      `deriving` clause, so to avoid unnecessary breakage, I opted to
      suppress these language extension checks for `deriving` clauses, just
      like we currently suppress them for `SPECIALIZE instance` pragmas.
      
      Test Plan: make test TEST=T14916
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14916
      
      Differential Revision: https://phabricator.haskell.org/D4501
      
      (cherry picked from commit 20f14b4f)
      1887441a
    • niteria's avatar
      Don't refer to blocks in debug info when -g1 · 59d73471
      niteria authored
      -g1 removes block information, but it turns out that procs can
      refer to block information through parents.
      Note [Splitting DebugBlocks] explains the parentage relationship.
      
      Test Plan:
      * ./validate
      * added a new test
      
      Reviewers: bgamari, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14894
      
      Differential Revision: https://phabricator.haskell.org/D4496
      
      (cherry picked from commit 0cbb13b3)
      59d73471
  7. 25 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Special-case record fields ending with hash when deriving Read · 32e18420
      Ryan Scott authored
      Summary:
      In commit dbd81f7e, a
      regression was inadvertently introduced which caused derived `Read`
      instances for record data types with fields ending in a `#` symbol
      (using `MagicHash`) would no longer parse on valid output. This
      is ultimately due to the same reasons as #5041, as we cannot parse
      a field name like `foo#` as a single identifier. We fix this issue
      by employing the same workaround as in #5041: first parse the
      identifier name `foo`, then then symbol `#`.
      
      This is accomplished by the new `readFieldHash` function in
      `GHC.Read`. This will likely warrant a `base-4.11.1.0` release.
      
      Test Plan: make test TEST=T14918
      
      Reviewers: tdammers, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14918
      
      Differential Revision: https://phabricator.haskell.org/D4502
      
      (cherry picked from commit d5577f44)
      32e18420
  8. 06 Mar, 2018 2 commits
    • Simon Marlow's avatar
      Fix interpreter with profiling · 0a3e2f32
      Simon Marlow authored
      This was broken by D3746 and/or D3809, but unfortunately we didn't
      notice because CI at the time wasn't building the profiling way.
      
      Test Plan:
      ```
      cd testsuite/test/profiling/should_run
      make WAY=ghci-ext-prof
      ```
      
      Reviewers: bgamari, michalt, hvr, erikd
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14705
      
      Differential Revision: https://phabricator.haskell.org/D4437
      
      (cherry picked from commit 488d63d6)
      0a3e2f32
    • niteria's avatar
      Allow top level ticked string literals · 2753d890
      niteria authored
      This reverts f5b275a2
      and changes the places that looked for `Lit (MachStr _))`
      to use `exprIsMbTickedLitString_maybe` to unwrap ticks as
      necessary.
      Also updated relevant comments.
      
      Test Plan:
      I added 3 new tests that previously reproduced.
      GHC HEAD now builds with -g
      
      Reviewers: simonpj, simonmar, bgamari, hvr, goldfire
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14779
      
      Differential Revision: https://phabricator.haskell.org/D4470
      
      (cherry picked from commit 5bc195a2)
      2753d890
  9. 19 Feb, 2018 1 commit
  10. 18 Feb, 2018 4 commits
    • Ryan Scott's avatar
      Implement stopgap solution for #14728 · c21a8cc2
      Ryan Scott authored
      It turns out that one can produce ill-formed Core by
      combining `GeneralizedNewtypeDeriving`, `TypeInType`, and
      `TypeFamilies`, as demonstrated in #14728. The root of the problem
      is allowing the last parameter of a class to appear in a //kind// of
      an associated type family, as our current approach to deriving
      associated type family instances simply doesn't work well for that
      situation.
      
      Although it might be possible to properly implement this feature
      today (see https://ghc.haskell.org/trac/ghc/ticket/14728#comment:3
      for a sketch of how this might work), there does not currently exist
      a performant implementation of the algorithm needed to accomplish
      this. Until such an implementation surfaces, we will make this corner
      case of `GeneralizedNewtypeDeriving` an error.
      
      Test Plan: make test TEST="T14728a T14728b"
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14728
      
      Differential Revision: https://phabricator.haskell.org/D4402
      
      (cherry picked from commit 1ede46d4)
      c21a8cc2
    • Ben Gamari's avatar
      testsuite: Add test for #14768 · 0bdf1b7a
      Ben Gamari authored
      (cherry picked from commit da468130)
      0bdf1b7a
    • Ömer Sinan Ağacan's avatar
      Collect CCs in CorePrep, including CCs in unfoldings · 583e392a
      Ömer Sinan Ağacan authored
      This patch includes two changes:
      
      1. Move cost centre collection from `SCCfinal` to `CorePrep`, to be able
         to collect cost centres in unfoldings. `CorePrep` drops unfoldings, so
         that's the latest stage in the compilation pipeline for this.
      
         After this change `SCCfinal` no longer collects all cost centres, but
         it still generates & collects CAF cost centres + updates cost centre
         stacks of `StgRhsClosure` and `StgRhsCon`s.
      
         This fixes #5889.
      
      2. Initialize cost centre stack fields of `StgRhs` in `coreToStg`. With
         this we no longer need to update cost centre stack fields in
         `SCCfinal`, so that module is removed.
      
         Cost centre initialization explained in Note [Cost-centre
         initialization plan].
      
         Because with -fcaf-all we need to attach a new cost-centre to each
         CAF, `coreTopBindToStg` now returns `CollectedCCs`.
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, simonmar
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #5889
      
      Differential Revision: https://phabricator.haskell.org/D4325
      
      (cherry picked from commit 59574058)
      583e392a
    • Ryan Scott's avatar
      Fix #14811 by wiring in $tcUnit# · 0f78f181
      Ryan Scott authored
      Previously, we were skipping over `$tcUnit#` entirely when
      wiring in `Typeable` tycons, resulting in #14811. Easily fixed.
      
      Test Plan: make test TEST=T14811
      
      Reviewers: bgamari, dfeuer
      
      Reviewed By: dfeuer
      
      Subscribers: dfeuer, rwbarton, thomie, carter
      
      GHC Trac Issues: #14811
      
      Differential Revision: https://phabricator.haskell.org/D4414
      
      (cherry picked from commit d5ac5820)
      0f78f181
  11. 09 Feb, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix isDroppableCt (Trac #14763) · f2bb550e
      Simon Peyton Jones authored
      When finishing up an implication constraint, it's a bit tricky to
      decide which Derived constraints to retain (for error reporting) and
      which to discard.  I got this wrong in commit
         f20cf982
         (Remove wc_insol from WantedConstraints)
      
      The particular problem in Trac #14763 was that we were reporting as an
      error a fundep-generated constraint
        (ex ~ T)
      where 'ex' is an existentially-bound variable in a pattern match.
      But this isn't really an error at all.
      
      This patch fixes the problem. Indeed, since I had to understand
      this rather tricky code, I took the opportunity to clean it up
      and document better.  See
        isDroppableCt :: Ct -> Bool
      and Note [Dropping derived constraints]
      
      I also removed wl_deriv altogether from the WorkList data type.  It
      was there in the hope of gaining efficiency by not even processing
      lots of derived constraints, but it has turned out that most derived
      constraints (notably equalities) must be processed anyway; see
      Note [Prioritise equalities] in TcSMonad.
      
      The two are coupled because to decide which constraints to put in
      wl_deriv I was using another variant of isDroppableCt.  Now it's much
      simpler -- and perhaps even more efficient too.
      
      (cherry picked from commit 6edafe3b)
      f2bb550e
  12. 04 Feb, 2018 1 commit
  13. 03 Feb, 2018 3 commits
    • Ryan Scott's avatar
      Don't apply dataToTag's caseRules for data families · b7f9139c
      Ryan Scott authored
      Commit 193664d4 added a
      special caseRule for `dataToTag`, but this transformation completely
      broke when `dataToTag` was applied to somewith with a type headed by
      a data family, leading to #14680. For now at least, the simplest
      solution is to simply not apply this transformation when the type is
      headed by a data family.
      
      Test Plan: make test TEST=T14680
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14680
      
      Differential Revision: https://phabricator.haskell.org/D4371
      
      (cherry picked from commit d8a0e6d3)
      b7f9139c
    • David Feuer's avatar
      Upgrade containers submodule · 445554b6
      David Feuer authored
      Reviewers: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4340
      
      (cherry picked from commit fdf518c7)
      445554b6
    • Alec Theriault's avatar
      Haddock needs to pass visible modules for instance filtering · 42a82cf4
      Alec Theriault authored
      The GHC-side `getNameToInstancesIndex` filters out incorrectly some
      instances because it is not aware of what modules are visible. Using
      `runTcInteractive` means that `ie_visible` gets initialized to a one
      module set containing some dummy GHCi module. This is clearly not the
      module set we want to check against to see if a given orphan instance
      is visible or not.
      
      In fact, GHC has no way of knowing what we want that module set to be
      since it doesn't know ahead of time which modules Haddock is making its
      docs for. The fix is just to pass that set in as an argument.
      
      Bumps haddock submodule.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: duog, alexbiehl, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4290
      
      (cherry picked from commit a47438e88e685971a81874565f2914043c8233c3)
      42a82cf4
  14. 01 Feb, 2018 7 commits
    • Ben Gamari's avatar
      testsuite: Fix test output broken by efba0546 · 233c5ced
      Ben Gamari authored
      Looks right to me.
      
      (cherry picked from commit 7d9812e8)
      233c5ced
    • Ben Gamari's avatar
      testsuite: Fix test output of T14715 · d6f2f231
      Ben Gamari authored
      Arguably the warning should just be disabled for this test to eliminate
      unnecessary wiggle in the future.
      
      (cherry picked from commit fe6fdf68)
      d6f2f231
    • Julian Priestley's avatar
      Don't add targets that can't be found in GHCi · 8f668bda
      Julian Priestley authored
      When using the :add command in haxlsh/ghci, a module/file that can't
      be found is still added to the list of targets, resulting in an error
      message for the bad module/file for every subsequent usage of the
      command. The add command should verify that the module/file can be
      found before adding it to the list of targets.
      
      Also add a ":show targets" command to show the currently added list of
      commands, and an ":unadd" command to remove a target.
      
      Test Plan:
      Add a new GHCi testcase that checks that :add doesn't remember either
      files or modules that could not be found, and that both the new :show
      and :unadd commands work as expected.
      
      Reviewers: simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14676
      
      Differential Revision: https://phabricator.haskell.org/D4321
      
      (cherry picked from commit 0bff9e67)
      8f668bda
    • Andreas Klebinger's avatar
      Mark xmm6 as caller saved in the register allocator for windows. · fe485f29
      Andreas Klebinger authored
      This prevents the register being picked up as a scratch register.
      Otherwise the allocator would be free to use it before a call. This
      fixes #14619.
      
      Test Plan: ci, repro case on #14619
      
      Reviewers: bgamari, Phyx, erikd, simonmar, RyanGlScott, simonpj
      
      Reviewed By: Phyx, RyanGlScott, simonpj
      
      Subscribers: simonpj, RyanGlScott, Phyx, rwbarton, thomie, carter
      
      GHC Trac Issues: #14619
      
      Differential Revision: https://phabricator.haskell.org/D4348
      
      (cherry picked from commit add4e1f1)
      fe485f29
    • Simon Peyton Jones's avatar
      Look inside implications in simplifyRule · d3573e4a
      Simon Peyton Jones authored
      Trac #14732 was a perpelexing bug in which -fdefer-typed-holes
      caused a mysterious type error in a RULE.  This turned out to
      be because we are more aggressive about creating implications
      when deferring (see TcUnify.implicationNeeded), and the rule
      mechanism hadn't caught up.
      
      This fixes it.
      
      (cherry picked from commit e9ae0cae)
      d3573e4a
    • Simon Peyton Jones's avatar
      Prioritise equalities when solving, incl deriveds · 77cdf60c
      Simon Peyton Jones authored
      We already prioritise equalities when solving, but
      Trac #14723 showed that we were not doing so consistently
      enough, and as a result the type checker could go into a loop.
      Yikes.
      
      See Note [Prioritise equalities] in TcSMonad.
      
      Fixng this bug changed the solve order enough to demonstrate
      a problem with fundeps: Trac #14745.
      
      (cherry picked from commit efba0546)
      77cdf60c
    • Simon Peyton Jones's avatar
      Move zonkWC to the right place in simplfyInfer · e6c14744
      Simon Peyton Jones authored
      runTcSWithEvBinds does some unification, so the zonkWC
      must be after, not before!  Yikes.  An outright bug.
      
      This fixes Trac #14715.
      
      (cherry picked from commit e7c3878d)
      e6c14744