1. 26 Mar, 2018 10 commits
    • 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
      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)
      bd85d963
    • Ö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
    • 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)
      b88228d5
    • 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
  2. 25 Mar, 2018 4 commits
  3. 08 Mar, 2018 3 commits
  4. 06 Mar, 2018 9 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
    • Ö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)
      0dc2a358
    • Ben Gamari's avatar
      Set RELEASE=YES, version 8.4.1 · 4b6c3b6f
      Ben Gamari authored
      4b6c3b6f
    • Ben Gamari's avatar
      Bump hsc2hs submodule · 3ba3fa6a
      Ben Gamari authored
      3ba3fa6a
    • Moritz Angermann's avatar
      add CCX=$(CXX) to integer-gmp · 76af0283
      Moritz Angermann authored
      Summary:
      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)
      76af0283
    • 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
    • Ben Gamari's avatar
      Another Cabal submodule bump · 201a5570
      Ben Gamari authored
      201a5570
    • Herbert Valerio Riedel's avatar
      Fixup include of gmp/config.mk to use new location · 57b9a433
      Herbert Valerio Riedel authored
      This wasn't spotted rightaway in
      8f0b2f5e
      because the include-site deliberately ignored include-errors as
      a Hack with the justification below:
      
      > Hack. The file gmp/config.mk doesn't exist yet after running ./configure in
      > the toplevel (ghc) directory. To let some toplevel make commands such as
      > sdist go through, right after ./configure, don't consider this an error.
      
      This may have contributed to #14891.
      
      (cherry picked from commit df7ac37d)
      57b9a433
    • niteria's avatar
      Correct -g flag description · 2df499b4
      niteria authored
      Since 7aaeaf81
      `-g1` and `-g2` are actually different.
      The tutorial below is correct.
      
      Test Plan: harbormaster
      
      Reviewers: bgamari, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4471
      
      (cherry picked from commit 5b1132eefd0a75189b3527486b492c3dffc7bdf1)
      2df499b4
  5. 04 Mar, 2018 2 commits
  6. 02 Mar, 2018 5 commits
  7. 25 Feb, 2018 3 commits
    • Sergey Vinokurov's avatar
      Fix typo · 739bb3ef
      Sergey Vinokurov authored
      (cherry picked from commit 37e78029845a04d0ab4cc05e1790c648facdcb1f)
      739bb3ef
    • Sergey Vinokurov's avatar
      List 'setEnv' as opposite of 'getEnv' · 1cd5d6cd
      Sergey Vinokurov authored
      It seems best to direct users to use 'System.Environment.setEnv'
      rather than 'System.Posix.Env.putEnv'. This is due to 'setEnv' being
      located in the same module as 'getEnv' and my virtue of working on
      Windows platform, whereas 'putEnv' does not have that quality because
      it's part of the 'unix' package.
      
      (cherry picked from commit c74fcf5d27744c67b09b29a78029c31c9371cf41)
      1cd5d6cd
    • Sergey Vinokurov's avatar
      Fix missing code example in changelog for 8.4.1 · 353ed7d7
      Sergey Vinokurov authored
      (cherry picked from commit 3ae408cf93d10b9a2e5acb4186dc8e0c62e0afb6)
      353ed7d7
  8. 24 Feb, 2018 1 commit
  9. 23 Feb, 2018 1 commit
  10. 20 Feb, 2018 1 commit
  11. 19 Feb, 2018 1 commit