1. 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)
  2. 13 Apr, 2018 3 commits
  3. 11 Apr, 2018 1 commit
    • Ben Gamari's avatar
      rts/RetainerProfile: Handle BLOCKING_QUEUES · 0ec1bd64
      Ben Gamari authored
      push() considers BLOCKING_QUEUES to be an invalid closure type which
      should never be present on the stack. However, retainClosure made no
      accomodation for this and ended up pushing such a closure. This lead
      to #14947.
      Test Plan: Validate
      Reviewers: simonmar, erikd
      Reviewed By: simonmar
      Subscribers: thomie, carter, RyanGlScott
      GHC Trac Issues: #14947
      Differential Revision: https://phabricator.haskell.org/D4538
      (cherry picked from commit d5f6d7a0)
  4. 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)
  5. 28 Mar, 2018 4 commits
  6. 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)
  7. 25 Mar, 2018 4 commits
  8. 08 Mar, 2018 3 commits
  9. 06 Mar, 2018 5 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)
    • Ömer Sinan Ağacan's avatar
      forkProcess: fix task mutex release order · 0dc2a358
      Ömer Sinan Ağacan authored
      `all_tasks_mutex` should be released before calling `releaseCapability_`
      in the parent process as `releaseCapability_` spawns worker tasks in
      some cases.
      Reviewers: bgamari, erikd, simonmar
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #14538
      Differential Revision: https://phabricator.haskell.org/D4460
      (cherry picked from commit e261b852)
    • Ben Gamari's avatar
      Set RELEASE=YES, version 8.4.1 · 4b6c3b6f
      Ben Gamari authored
    • Ben Gamari's avatar
      Bump hsc2hs submodule · 3ba3fa6a
      Ben Gamari authored
    • Moritz Angermann's avatar
      add CCX=$(CXX) to integer-gmp · 76af0283
      Moritz Angermann authored
      This came up when trying to build GHC HEAD with nix. We
      do not set CCX for integer-gmp when running ./configure. We do
      this however for libffi.
      The result is, that if CCX is not set, we default to the system
      one, of which there might be none (as in nixos's case).  This
      will not show on a debian+nix or similar setup, where the system
      `cxx` is still in place, and only shows up when the system tries
      hard to sandbox everything (even cxx) as nixOS does.
      We use `CXX`, which is set to either `clang` or `CC_STAGE1`, and
      also usedfor `CC`, similar to what we do for libffi.c
      Test Plan: ./validate
      Reviewers: bgamari, hvr
      Reviewed By: hvr
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4473
      (cherry picked from commit cf5bc96e)