1. 14 Nov, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix a TyVar bug in the flattener · 0a851903
      Simon Peyton Jones authored
      A year ago I gave up on trying to rigorously separate TyVars
      from TcTyVars, and instead allowed TyVars to appear rather more
      freely in types examined by the constraint solver:
      
         commit 18d0bdd3
         Author: Simon Peyton Jones <simonpj@microsoft.com>
         Date:   Wed Nov 23 16:00:00 2016 +0000
      
         Allow TyVars in TcTypes
      
      See Note [TcTyVars in the typechecker] in TcType.
      
      However, TcFlatten.flatten_tyvar1 turned out to treat
      a TyVar specially, and implicitly assumed that it could
      not have an equality constraint in the inert set.  Wrong!
      
      This caused Trac #14450.  Fortunately it is easily fixed,
      by deleting code.
      0a851903
  2. 11 Oct, 2017 1 commit
    • Simon Peyton Jones's avatar
      Avoid creating dependent types in FloatOut · 4bb54a45
      Simon Peyton Jones authored
      This bug was exposed by Trac #14270.  The problem and its cure
      is described in SetLevels, Note [Floating and kind casts].
      
      It's simple and will affect very few programs.  But the very
      fact that it was so unexpected is discomforting.
      4bb54a45
  3. 03 Oct, 2017 1 commit
  4. 29 Sep, 2017 1 commit
  5. 25 Sep, 2017 1 commit
    • Simon Peyton Jones's avatar
      Improve type-error reporting · 1b476ab5
      Simon Peyton Jones authored
      This patch does two things:
      
      * When reporting a hole, we now include its kind if the
        kind is not just '*'.  This addresses Trac #14265
      
      * When reporting things like "'a' is a rigid type varaible
        bound by ...", this patch arranges to group the type variables
        together, so we don't repeat the "bound by..." stuff endlessly
      1b476ab5
  6. 13 Sep, 2017 1 commit
  7. 05 Sep, 2017 1 commit
    • Ryan Scott's avatar
      Implicitly bind kind variables in type family instance RHSes when it's sensible · 0829821a
      Ryan Scott authored
      Summary:
      Before, there was a discrepancy in how GHC renamed type synonyms as
      opposed to type family instances. That is, GHC would accept definitions like
      this one:
      
      ```lang=haskell
      type T = (Nothing :: Maybe a)
      ```
      
      However, it would not accept a very similar type family instance:
      
      ```lang=haskell
      type family   T :: Maybe a
      type instance T = (Nothing :: Maybe a)
      ```
      
      The primary goal of this patch is to bring the renaming of type family
      instances up to par with that of type synonyms, causing the latter definition
      to be accepted, and fixing #14131.
      
      In particular, we now allow kind variables on the right-hand sides of type
      (and data) family instances to be //implicitly// bound by LHS type (or kind)
      patterns (as opposed to type variables, which must always be explicitly
      bound by LHS type patterns only). As a consequence, this allows programs
      reported in #7938 and #9574 to typecheck, whereas before they would
      have been rejected.
      
      Implementation-wise, there isn't much trickery involved in making this happen.
      We simply need to bind additional kind variables from the RHS of a type family
      in the right place (in particular, see `RnSource.rnFamInstEqn`, which has
      undergone a minor facelift).
      
      While doing this has the upside of fixing #14131, it also made it easier to
      trigger #13985, so I decided to fix that while I was in town. This was
      accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13985, #14131
      
      Differential Revision: https://phabricator.haskell.org/D3872
      0829821a
  8. 29 Aug, 2017 1 commit
    • Simon Peyton Jones's avatar
      Refactor bindHsQTyVars and friends · 0257dacf
      Simon Peyton Jones authored
      This work was triggered by Trac #13738, which revealed to me that
      the code RnTypes.bindHsQTyVars and bindLHsTyVarBndrs was a huge
      tangled mess -- and outright wrong on occasion as the ticket showed.
      
      The big problem was that bindLHsTyVarBndrs (which is invoked at every
      HsForAll, including nested higher rank ones) was attempting to bind
      implicit kind variables, which it has absolutely no busineess doing.
      Imlicit kind quantification is done at the outside only, in fact
      precisely where we have HsImplicitBndrs or LHsQTyVars (which also
      has implicit binders).
      
      Achieving this move was surprisingly hard, because more and more
      barnacles had accreted aroud the original mistake.  It's much
      much better now.
      
      Summary of changes.  Almost all the action is in RnTypes.
      
      * Implicit kind variables are bound only by
        - By bindHsQTyVars, which deals with LHsQTyVars
        - By rnImplicitBndrs, which deals with HsImplicitBndrs
      
      * bindLHsTyVarBndrs, and bindLHsTyVarBndr are radically simplified.
        They simply does far less, and have lots their forest of
        incomprehensible accumulating parameters.  (To be fair, some of
        the code in bindLHsTyVarBndrs just moved to bindHsQTyVars, but
        in much more perspicuous form.)
      
      * The code that checks if a variable appears in both a kind and
        a type (triggering RnTypes.mixedVarsErr) was bizarre.  E.g.
        we had this in RnTypes.extract_hs_tv_bndrs
             ; check_for_mixed_vars bndr_kvs acc_tvs
             ; check_for_mixed_vars bndr_kvs body_tvs
             ; check_for_mixed_vars body_tvs acc_kvs
             ; check_for_mixed_vars body_kvs acc_tvs
             ; check_for_mixed_vars locals body_kvs
        I cleaned all this up; now we check for mixed use at binding
        sites only.
      
      * Checks for "Variable used as a kind before being bound", like
           data T (a :: k) k = rhs
        now just show up straightforwardly as "k is not in scope".
        See Note [Kind variable ordering]
      
      * There are some knock-on simplifications in RnSource.
      0257dacf
  9. 18 Aug, 2017 1 commit
  10. 19 May, 2017 1 commit
  11. 09 May, 2017 1 commit
  12. 04 May, 2017 1 commit
  13. 23 Apr, 2017 1 commit
    • Ryan Scott's avatar
      Document the kind generalization behavior observed in #13555 · 18c3a7ea
      Ryan Scott authored
      The conclusion of #13555 was that a program which began to fail to
      typecheck (starting in GHC 8.2) was never correct to begin with. Let's
      document why this is the case with respect to `MonoLocalBinds`'
      interaction with kind generalization. Also adds the reported program as
      a `compile_fail` testcase.
      
      Test Plan: make test TEST=T13555 # Also, read the docs
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Reviewed By: goldfire, simonpj, bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13555
      
      Differential Revision: https://phabricator.haskell.org/D3472
      18c3a7ea
  14. 10 Mar, 2017 2 commits
    • Simon Peyton Jones's avatar
      Fix TcSimplify.decideQuantification for kind variables · 7e96526a
      Simon Peyton Jones authored
      TcSimplify.decideQuantification was doing the Wrong Thing when
      "growing" the type variables to quantify over. We were trying to do
      this on a tyvar set where we'd split off the dependent type varaibles;
      and we just got it wrong.  A kind variable wasn't being generalised
      properly, with confusing knock on consequences.
      
      All this led to Trac #13371 and Trac #13393.
      
      This commit tidies it all up:
      
      * The type TcDepVars is renamed as CandidateQTvs;
        and splitDepVarsOfType to candidateQTyVarsOfType
      
      * The code in TcSimplify.decideQuantification is simpler.
        It no longer does the tricky "grow" stuff over TcDepVars.
        Instead it use ordinary VarSets (thereby eliminating the
        nasty growThetaTyVarsDSet) and uses that to filter the
        result of candidateQTyVarsOfType.
      
      * I documented that candidateQTyVarsOfType returns the type
        variables in a good order in which to quantify, and rewrote
        it to use an accumulator pattern, so that we would predicatably
        get left-to-right ordering.
      
      In doing all this I also made UniqDFM behave a little more nicely:
      
      * When inserting an element that is there already, keep the old tag,
        while still overwriting with the new value.
      
      * This means that when doing udfmToList we get back elements in the
        order they were originally inserted, rather than in reverse order.
      
      It's not a big deal, but in a subsequent commit I use it to improve
      the order of type variables in inferred types.
      
      All this led to a lot of error message wibbles:
       - changing the order of quantified variables
       - changing the order in which instances are listed in GHCi
       - changing the tidying of variables in typechecker erors
      
      There's a submodule update for 'array' because one of its tests
      has an error-message change.
      
      I may not have associated all of them with the correct commit.
      7e96526a
    • Simon Peyton Jones's avatar
      Deal with JoinIds before void types · bc0f3abd
      Simon Peyton Jones authored
      Trac #13394, comment:4 showed up another place where we were testing
      for the representation of of a type; and it turned out to be a JoinId
      which can be rep-polymorphic.
      
      Just putting the test in the right places solves this easily.
      bc0f3abd
  15. 08 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Join points can be levity-polymorphic · 8e053700
      Simon Peyton Jones authored
      It's ok to have a levity-polymorphic join point, thus
         let j :: r :: TYPE l = blah
         in ...
      
      Usually we don't allow levity-polymorphic binders, but join points
      are different because they are not first class.  I updated the
      invariants in CoreSyn.
      
      This commit fixes Trac #13394.
      8e053700
  16. 21 Feb, 2017 1 commit
    • Simon Peyton Jones's avatar
      Disallow class instances for synonyms · c7508083
      Simon Peyton Jones authored
      See Trac #13267 and Note [Instances and constraint synonyms]
      in TcValidity.
      
      We can't easily do a perfect job, because the rename is really trying
      to do its lookup too early.  But this is at least an improvement.
      c7508083
  17. 22 Jan, 2017 1 commit
  18. 01 Dec, 2016 1 commit
  19. 28 Nov, 2016 1 commit
    • Simon Peyton Jones's avatar
      Test Trac #12885 · 27a6bdf0
      Simon Peyton Jones authored
      ...which is fixed by
      
        commit 0476a64e
        Author: Simon Peyton Jones <simonpj@microsoft.com>
        Date:   Tue Oct 25 15:22:17 2016 +0100
      
          Fix a bug in mk_superclasses_of
      27a6bdf0
  20. 25 Nov, 2016 1 commit
    • Simon Peyton Jones's avatar
      Another major constraint-solver refactoring · 1eec1f21
      Simon Peyton Jones authored
      This patch takes further my refactoring of the constraint
      solver, which I've been doing over the last couple of months
      in consultation with Richard.
      
      It fixes a number of tricky bugs that made the constraint
      solver actually go into a loop, including
      
        Trac #12526
        Trac #12444
        Trac #12538
      
      The main changes are these
      
      * Flatten unification variables (fmvs/fuvs) appear on the LHS
        of a tvar/tyvar equality; thus
                 fmv ~ alpha
        and not
                 alpha ~ fmv
      
        See Note [Put flatten unification variables on the left]
        in TcUnify.  This is implemented by TcUnify.swapOverTyVars.
      
      * Don't reduce a "loopy" CFunEqCan where the fsk appears on
        the LHS:
            F t1 .. tn ~ fsk
        where 'fsk' is free in t1..tn.
        See Note [FunEq occurs-check principle] in TcInteract
      
        This neatly stops some infinite loops that people reported;
        and it allows us to delete some crufty code in reduce_top_fun_eq.
        And it appears to be no loss whatsoever.
      
        As well as fixing loops, ContextStack2 and T5837 both terminate
        when they didn't before.
      
      * Previously we generated "derived shadow" constraints from
        Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly
        generate a derived shadow from the same Wanted.
      
        A big change in this patch is to have two kinds of Wanteds:
           [WD] behaves like a pair of a Wanted and a Derived
           [W]  behaves like a Wanted only
        See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh
        field of a Wanted.
      
        This turned out to be a lot simpler.  A [WD] gets split into a
        [W] and a [D] in TcSMonad.maybeEmitShaodow.
      
        See TcSMonad Note [The improvement story and derived shadows]
      
      * Rather than have a separate inert_model in the InertCans, I've
        put the derived equalities back into inert_eqs.  We weren't
        gaining anything from a separate field.
      
      * Previously we had a mode for the constraint solver in which it
        would more aggressively solve Derived constraints; it was used
        for simplifying the context of a 'deriving' clause, or a 'default'
        delcaration, for example.
      
        But the complexity wasn't worth it; now I just make proper Wanted
        constraints.  See TcMType.cloneWC
      
      * Don't generate injectivity improvement for Givens; see
        Note [No FunEq improvement for Givens] in TcInteract
      
      * solveSimpleWanteds leaves the insolubles in-place rather than
        returning them.  Simpler.
      
      I also did lots of work on comments, including fixing Trac #12821.
      1eec1f21
  21. 27 Oct, 2016 1 commit
  22. 30 Sep, 2016 1 commit
    • 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
  23. 30 Jun, 2016 1 commit
  24. 13 Jun, 2016 2 commits
  25. 10 May, 2016 1 commit
  26. 29 Apr, 2016 1 commit
  27. 16 Mar, 2016 1 commit
  28. 15 Mar, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11648. · 55577a91
      eir@cis.upenn.edu authored
      We now check that a CUSK is really a CUSK and issue an error if
      it isn't. This also involves more solving and zonking in
      kcHsTyVarBndrs, which was the outright bug reported in #11648.
      
      Test cases: polykinds/T11648{,b}
      
      This updates the haddock submodule.
      
      [skip ci]
      55577a91
  29. 26 Feb, 2016 1 commit
  30. 15 Feb, 2016 1 commit
  31. 10 Feb, 2016 1 commit
  32. 08 Feb, 2016 2 commits
    • Simon Peyton Jones's avatar
      Fix a nasty superclass expansion bug · 43e02d12
      Simon Peyton Jones authored
      This patch fixes Trac #11523.
      
      * The basic problem was that TcRnTypes.superClassesMightHelp was
        returning True of a Derived constraint, and that led to us
        expanding Given superclasses, which produced the same Derived
        constraint again, and so on infinitely.  We really want to do
        this only if there are unsolve /Wanted/ contraints!
      
      * On the way I made TcSMonad.getUnsolvedInerts a bit more
        discriminating about which Derived equalities it returns;
        see Note [Unsolved Derived equalities] in TcSMonad
      
      * Lots of new comments in TcSMonad.
      43e02d12
    • Simon Peyton Jones's avatar
      Add Edward Kmett's example as a test case · 4e653012
      Simon Peyton Jones authored
      This is a more stressful example of T11480.
      4e653012
  33. 25 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Special-case implicit params in superclass expansion · ff21795a
      Simon Peyton Jones authored
      This issue came up in Trac #11480, and is documented in
      Note [When superclasses help] in TcRnTypes.
      
      We were getting a spurious warning
        T11480.hs:1:1: warning:
           solveWanteds: too many iterations (limit = 4)
      
      The fix is easy.  A bit of refactoring along the way.
      
      The original bug report in Trac #11480 appears to work
      fine in HEAD and the 8.0 branch but I added a regression
      test in this commit as well.
      ff21795a
  34. 21 Jan, 2016 2 commits
  35. 26 Dec, 2015 1 commit
  36. 24 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Visible type application · 2db18b81
      eir@cis.upenn.edu authored
      This re-working of the typechecker algorithm is based on
      the paper "Visible type application", by Richard Eisenberg,
      Stephanie Weirich, and Hamidhasan Ahmed, to be published at
      ESOP'16.
      
      This patch introduces -XTypeApplications, which allows users
      to say, for example `id @Int`, which has type `Int -> Int`. See
      the changes to the user manual for details.
      
      This patch addresses tickets #10619, #5296, #10589.
      2db18b81