1. 20 May, 2018 2 commits
    • Ö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)
    • Ben Gamari's avatar
      rts: Fix compaction of SmallMutArrPtrs · 0d40fd75
      Ben Gamari authored
      This was blatantly wrong due to copy-paste blindness:
       * labels were shadowed, which GHC doesn't warn about(!), resulting in
         plainly wrong behavior
       * the sharing check was omitted
       * the wrong closure layout was being used
      Moreover, the test wasn't being run due to its primitive dependency, so
      I didn't even notice. Sillyness.
      Test Plan: install `primitive`, `make test TEST=compact_small_array`
      Reviewers: simonmar, erikd
      Reviewed By: simonmar
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #13857.
      Differential Revision: https://phabricator.haskell.org/D4702
      (cherry picked from commit 12deb9a9)
  2. 13 May, 2018 1 commit
  3. 02 May, 2018 1 commit
  4. 20 Apr, 2018 1 commit
  5. 19 Apr, 2018 1 commit
  6. 17 Apr, 2018 3 commits
  7. 16 Apr, 2018 1 commit
  8. 14 Apr, 2018 5 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)
    • Joachim Breitner's avatar
      In Exitify, zap idInfo of abstracted variables (fixes #15005) · 2f5b97c3
      Joachim Breitner authored
      as helpfully outlined by SPJ.
      This commit copies a small bit code from `SetLevels` which could
      reasonably be put in `Id` as `zapAllIdinfo`; I did not do this to make
      merging this commmit into `ghc-8.4` easier.
      If this commit gets merged, then presumably after commit
      3f59d380 (test case) and
      ae0cff0a (other fixes to Exitify.hs).
      Differential Revision: https://phabricator.haskell.org/D4582
      (cherry picked from commit 3cfb12d8)
    • 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
      (cherry picked from commit 3f59d380)
    • 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)
    • Ryan Scott's avatar
      Correct FixIOException's @since annotation retroactively · 8147fa32
      Ryan Scott authored
      In D4113, a `FixIOException` data type was added with a
      `@since TODO` annotation, but it seems that `TODO` made it out into
      `base-4.11` itself. I've (retroactively) fixed this and added an
      entry to the `base-4.11` entry in the `changelog`.
      Test Plan: Read it
      Reviewers: dfeuer, hvr, bgamari
      Reviewed By: dfeuer
      Subscribers: thomie, carter
      GHC Trac Issues: #14356, #15025
      Differential Revision: https://phabricator.haskell.org/D4578
      (cherry picked from commit ce27c7d5)
  9. 13 Apr, 2018 3 commits
  10. 11 Apr, 2018 1 commit
  11. 29 Mar, 2018 4 commits
    • Ben Gamari's avatar
      Bump haddock submodule again · 6d7eecff
      Ben Gamari authored
    • Ryan Scott's avatar
      Don't permit data types with return kind Constraint · b5c50241
      Ryan Scott authored
      Previously, GHC allowed all of the following:
      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
      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)
    • 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)
    • Ö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)
  12. 28 Mar, 2018 4 commits
  13. 26 Mar, 2018 11 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)
    • 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)
    • 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)
    • 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)
    • 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)
    • 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)
    • Ömer Sinan Ağacan's avatar
      Fix a debug print in disassembler (#14905) · bd85d963
      Ömer Sinan Ağacan authored
      When interpreter is not profiled (see `interpreterProfiled` in
      `DynFlags`) bytecode generator generates a NULL pointer as the cost
      centre of a `BRK_FUN` instruction:
          let cc | interpreterProfiled dflags = cc_arr ! tick_no
                 | otherwise = toRemotePtr nullPtr
          let breakInstr = BRK_FUN (fromIntegral tick_no) (getUnique this_mod) cc
          return $ breakInstr `consOL` code
      We now take this into account when disassembling `BRK_FUN`.
      Reviewers: bgamari, simonmar, erikd
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4490
      (cherry picked from commit 8e341013)
    • Ö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)
    • Ben Gamari's avatar
      base: Fix Unicode handling of TyCon's Show instance · b88228d5
      Ben Gamari authored
      Test Plan: `make test TEST=T14925`
      Reviewers: hvr, dfeuer
      Reviewed By: dfeuer
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #14925
      Differential Revision: https://phabricator.haskell.org/D4530
      (cherry picked from commit 20ae19fc)
    • 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)
    • 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)
  14. 25 Mar, 2018 2 commits