1. 01 Oct, 2016 1 commit
    • Ryan Scott's avatar
      Implement deriving strategies · 9e862765
      Ryan Scott authored
      Allows users to explicitly request which approach to `deriving` to use
      via keywords, e.g.,
      
      ```
      newtype Foo = Foo Bar
        deriving Eq
        deriving stock    Ord
        deriving newtype Show
      ```
      
      Fixes #10598. Updates haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin,
      erikd, simonmar
      
      Reviewed By: alanz, bgamari, simonpj
      
      Subscribers: thomie, mpickering, oerjan
      
      Differential Revision: https://phabricator.haskell.org/D2280
      
      GHC Trac Issues: #10598
      9e862765
  2. 30 Sep, 2016 10 commits
    • Ryan Scott's avatar
      Document Safe Haskell restrictions on Generic instances · b3d55e20
      Ryan Scott authored
      Commit 578fbeca disallowed hand-written
      `Generic` instances in Safe Haskell, but this wasn't documented anywhere.
      b3d55e20
    • Gabor Greif's avatar
      Correct spelling in note references · 28a00eaf
      Gabor Greif authored
      28a00eaf
    • Simon Peyton Jones's avatar
      Make tcrun042 fail · 3f27237b
      Simon Peyton Jones authored
      This test uses wholesale impredicative polymorphism, and now fails.
      That's ok.
      3f27237b
    • Simon Peyton Jones's avatar
      Add missing stderr file · 5d473cd6
      Simon Peyton Jones authored
      ..accidentally omitted from previous commit.
      5d473cd6
    • Simon Peyton Jones's avatar
      Comments only · fc4ef667
      Simon Peyton Jones authored
      fc4ef667
    • Simon Peyton Jones's avatar
      Fix impredicativity (again) · b612da66
      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.
      b612da66
    • Simon Peyton Jones's avatar
      Add Outputable Report in TcErrors · 3012c431
      Simon Peyton Jones authored
      ...just for debug output
      3012c431
    • Simon Peyton Jones's avatar
      Fix a bug in occurs checking · 66a8c194
      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.
      66a8c194
    • Simon Peyton Jones's avatar
      Fix desugaring of pattern bindings (again) · 2fbfbca2
      Simon Peyton Jones authored
      This patch fixes Trac #12595.  The problem was with a
      pattern binding like
           !x = e
      For a start it's silly to match that pattern and build
      a unit tuple (the General Case of mkSelectorBinds); but
      that's what was happening because the bang fell through
      to the general case.  But for a variable pattern building
      any auxiliary bindings is stupid.  So the patch
      introduces a new case in mkSelectorBinds for variable
      patterns.
      
      Then it turned out that if 'e' was a plain variable, and
      moreover was imported GlobalId, then matchSinglePat made
      it a /bound/ variable, which should never happen.  That
      ultimately caused a linker error, but the original bug
      was much earlier.
      2fbfbca2
    • Simon Peyton Jones's avatar
      A bit of tracing about flattening · 0b533a25
      Simon Peyton Jones authored
      0b533a25
  3. 29 Sep, 2016 2 commits
  4. 28 Sep, 2016 1 commit
  5. 27 Sep, 2016 1 commit
  6. 26 Sep, 2016 3 commits
  7. 24 Sep, 2016 3 commits
  8. 23 Sep, 2016 5 commits
    • Matthew Pickering's avatar
      Mark mapUnionFV as INLINABLE rather than INLINE · d1229353
      Matthew Pickering authored
      It is a self-recursive function so will always be the loop-breaker
      and hence never able to be inlined. It is dubious whether the INLINABLE
      pragma will ever help as it is not a very polymorphic function
      but some specialisation could occur.
      d1229353
    • Richard Eisenberg's avatar
      Fix #12442. · 9766b0c8
      Richard Eisenberg authored
      The problem is described in the ticket.
      
      This patch adds new variants of the access points to the pure
      unifier that allow unification of types only when the caller
      wants this behavior. (The unifier used to also unify kinds.)
      This behavior is appropriate when the kinds are either already
      known to be the same, or the list of types provided are a
      list of well-typed arguments to some type constructor. In the
      latter case, unifying earlier types in the list will unify the
      kinds of any later (dependent) types.
      
      At use sites, I went through and chose the unification function
      according to the criteria above.
      
      This patch includes some modest performance improvements as we
      are now doing less work.
      9766b0c8
    • Simon Marlow's avatar
      Improved documentation for Foreign.Concurrent (#12547) · 3a17916b
      Simon Marlow authored
      We had better docs for the underlying functions in GHC.ForeignPtr, but
      this wasn't propagated to the re-exported versions in
      Foreign.Concurrent.
      3a17916b
    • Simon Marlow's avatar
      Expose hs_exit_(rtsFalse) as hs_exit_nowait() · 74c4ca02
      Simon Marlow authored
      Summary: And document it.  See the docmentation for the reason I want this.
      
      Test Plan: It's an existing API, just exposing it.
      
      Reviewers: bgamari, niteria, austin, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2531
      74c4ca02
    • Simon Marlow's avatar
      shutdownHaskellAndExit: just do a normal hs_exit() (#5402) · 9cbcdb48
      Simon Marlow authored
      If we want to keep the RTS alive a bit longer by having another
      hs_init()/hs_exit() pair in a library that will destruct itself after
      main() has exited, then the forced shutdown here thwarts that.
      
      I think we just "fixed" #5402 in the wrong way before, this should be
      better.
      9cbcdb48
  9. 21 Sep, 2016 1 commit
    • Tamar Christina's avatar
      Fix failing test T12504 · 8bd3d417
      Tamar Christina authored
      Summary:
      Test T12504 does it's checking in the Makefile using grep but still specified an stdout.
      the stdout has the old output and would always fail.
      
      Since the stdout isn't needed, let's not check it.
      
      Test Plan: make test TEST=T12504
      
      Reviewers: bgamari, austin, erikd, rcook
      
      Reviewed By: rcook
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2537
      
      GHC Trac Issues: #12504
      8bd3d417
  10. 20 Sep, 2016 2 commits
  11. 16 Sep, 2016 1 commit
    • Ben Gamari's avatar
      Remove directories from include paths · ea310f99
      Ben Gamari authored
      Previously this was a relative path which worked in the GHC tree, but
      failed elsewhere. This caused trouble for out-of-tree users as well as
      Hadrian, which wants to move build artifacts out of the working
      directory. Fixes #8040.
      
      Test Plan: Validate
      
      Reviewers: thomie, austin, snowleopard, hvr
      
      Reviewed By: snowleopard, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2530
      
      GHC Trac Issues: #8040
      ea310f99
  12. 15 Sep, 2016 6 commits
  13. 13 Sep, 2016 3 commits
  14. 12 Sep, 2016 1 commit