1. 30 Sep, 2016 5 commits
    • 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
  2. 29 Sep, 2016 1 commit
  3. 28 Sep, 2016 1 commit
  4. 26 Sep, 2016 3 commits
  5. 24 Sep, 2016 1 commit
    • Joachim Breitner's avatar
      Replace INLINEABLE by INLINABLE (#12613) · 68f72f10
      Joachim Breitner authored
      as the latter is the official, correct spelling, and the former just a
      misspelling accepted by GHC.
      
      Also document in the user’s guide that the alternative spelling is
      accepted
      
      This commit was brough to you by HIW 2016.
      68f72f10
  6. 23 Sep, 2016 2 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
  7. 20 Sep, 2016 1 commit
  8. 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
  9. 15 Sep, 2016 3 commits
    • Simon Peyton Jones's avatar
      Comments only · a0012992
      Simon Peyton Jones authored
      a0012992
    • Ben Gamari's avatar
      Unify CallStack handling in ghc · 626db8f8
      Ben Gamari authored
      Here we introduce compatibility wrappers for HasCallStack constraints.
      This is necessary as we must support GHC 7.10.1 which lacks sane call
      stack support. We also introduce another constraint synonym,
      HasDebugCallStack, which only provides a call stack when DEBUG is set.
      626db8f8
    • Simon Marlow's avatar
      Fix codegen bug in PIC version of genSwitch (#12433) · 86836a2e
      Simon Marlow authored
      Summary:
      * getNonClobberedReg instead of getSomeReg, because the reg needs to
        survive across t_code
      * Use a new reg for the table offset calculation instead of clobbering
        the reg returned by expr (this was the bug affecting #12433)
      
      Test Plan: New unit test; validate
      
      Reviewers: rwbarton, bgamari, austin, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2529
      
      GHC Trac Issues: #12433
      86836a2e
  10. 13 Sep, 2016 3 commits
  11. 12 Sep, 2016 2 commits
    • Simon Peyton Jones's avatar
      Remove unused exports · 21d0bfe1
      Simon Peyton Jones authored
      21d0bfe1
    • Simon Peyton Jones's avatar
      Be less picky about reporing inaccessible code · 03541cba
      Simon Peyton Jones authored
      Triggered by the discussion on Trac #12466, this patch
      makes GHC less aggressive about reporting an error when
      there are insoluble Givens.
      
      Being so agressive was making some libraries fail to
      compile, and is arguably wrong in at least some cases.
      See the discussion on the ticket.
      
      Several test now pass when they failed before; see
      the files-modified list for this patch.
      03541cba
  12. 11 Sep, 2016 3 commits
  13. 10 Sep, 2016 1 commit
    • Ryan Scott's avatar
      Remove -flocal-ghci-history from default flags · 7b4bb405
      Ryan Scott authored
      Summary:
      D2461 seemed to (inadvertently, I think) add the
      `-flocal-ghci-history` flag to the list of `defaultFlags` that are enabled
      automatically. As a result, every invocation of `ghci` caused a local GHCi
      history to be saved to the current directory, which probably shouldn't be the
      default.
      
      Test Plan:
      Run `ghci`, observe the lack of a `.ghci_history` file in your
      working directory
      
      Reviewers: austin, thomie, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: ak3n
      
      Differential Revision: https://phabricator.haskell.org/D2520
      
      GHC Trac Issues: #9089
      7b4bb405
  14. 09 Sep, 2016 1 commit
    • Alan Zimmerman's avatar
      Add hook for creating ghci external interpreter · 65d9597d
      Alan Zimmerman authored
      Summary:
      The external interpreter is launched by calling
      'System.Process.createProcess' with a 'CreateProcess' parameter.
      
      The current value for this has the 'std_in', 'std_out' and 'std_err'
      fields use the default of 'Inherit', meaning that the remote interpreter
      shares the stdio with the original ghc/ghci process.
      
      This patch introduces a new hook to the DynFlags, which has an
      opportunity to override the 'CreateProcess' fields, launch the process,
      and retrieve the stdio handles actually used.
      
      So if a ghci external interpreter session is launched from the GHC API
      the stdio can be redirected if required, which is useful for tooling/IDE
      integration.
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, simonmar, bgamari
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2518
      65d9597d
  15. 05 Sep, 2016 4 commits
  16. 04 Sep, 2016 1 commit
  17. 03 Sep, 2016 2 commits
  18. 02 Sep, 2016 3 commits
  19. 01 Sep, 2016 2 commits