1. 19 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14710 with more validity checks during renaming · 447d1264
      Ryan Scott authored
      Summary:
      #14710 revealed two unfortunate regressions related to kind
      polymorphism that had crept in in recent GHC releases:
      
      1. While GHC was able to catch illegal uses of kind polymorphism
         (i.e., if `PolyKinds` wasn't enabled) in limited situations, it
         wasn't able to catch kind polymorphism of the following form:
      
      ```lang=haskell
      f :: forall a. a -> a
      f x = const x g
        where
          g :: Proxy (x :: a)
          g = Proxy
      ```
      
      Note that the variable `a` is being used as a kind variable in the
      type signature of `g`, but GHC happily accepts it, even without
      the use of `PolyKinds`.
      
      2. If you have `PolyKinds` (but not `TypeInType`) enabled, then GHC
         incorrectly accepts the following definition:
      
      ```lang=haskell
      f :: forall k (a :: k). Proxy a
      f = Proxy
      ```
      
      Even though `k` is explicitly bound and then later used as a kind
      variable within the same telescope.
      
      This patch fixes these two bugs as follows:
      
      1. Whenever we rename any `HsTyVar`, we check if the following three
         criteria are met:
      
         (a) It's a type variable
         (b) It's used at the kind level
         (c) `PolyKinds` is not enabled
      
         If so, then we have found an illegal use of kind polymorphism, so
         throw an error.
      
         This check replaces the `checkBadKindBndrs` function, which could
         only catch illegal uses of kind polymorphism in very limited
         situations (when the bad kind variable happened to be implicitly
         quantified in the same type signature).
      
      2. In `extract_hs_tv_bndrs`, we must error if `TypeInType` is not
         enabled and either of the following criteria are met:
      
         (a) An explicitly bound type variable is used in kind position
             in the body of a `forall` type.
         (b) An explicitly bound type variable is used in kind position
             in the kind of a bound type variable in a `forall` type.
      
         `extract_hs_tv_bndrs` was checking (a), but not (b). Easily fixed.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, bgamari, hvr
      
      Reviewed By: simonpj
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #14710
      
      Differential Revision: https://phabricator.haskell.org/D4554
      447d1264
  2. 06 Apr, 2018 1 commit
  3. 01 Apr, 2018 1 commit
    • Richard Eisenberg's avatar
      Track type variable scope more carefully. · faec8d35
      Richard Eisenberg authored
      The main job of this commit is to track more accurately the scope
      of tyvars introduced by user-written foralls. For example, it would
      be to have something like this:
      
        forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool
      
      In that type, a's kind must be k, but k isn't in scope. We had a
      terrible way of doing this before (not worth repeating or describing
      here, but see the old tcImplicitTKBndrs and friends), but now
      we have a principled approach: make an Implication when kind-checking
      a forall. Doing so then hooks into the existing machinery for
      preventing skolem-escape, performing floating, etc. This also means
      that we bump the TcLevel whenever going into a forall.
      
      The new behavior is done in TcHsType.scopeTyVars, but see also
      TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
      rewriting. There are several Notes near there to guide you. Of
      particular interest there is that Implication constraints can now
      have skolems that are out of order; this situation is reported in
      TcErrors.
      
      A major consequence of this is a slightly tweaked process for type-
      checking type declarations. The new Note [Use SigTvs in kind-checking
      pass] in TcTyClsDecls lays it out.
      
      The error message for dependent/should_fail/TypeSkolEscape has become
      noticeably worse. However, this is because the code in TcErrors goes to
      some length to preserve pre-8.0 error messages for kind errors. It's time
      to rip off that plaster and get rid of much of the kind-error-specific
      error messages. I tried this, and doing so led to a lovely error message
      for TypeSkolEscape. So: I'm accepting the error message quality regression
      for now, but will open up a new ticket to fix it, along with a larger
      error-message improvement I've been pondering. This applies also to
      dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.
      
      Other minor changes:
       - isUnliftedTypeKind didn't look for tuples and sums. It does now.
      
       - check_type used check_arg_type on both sides of an AppTy. But the left
         side of an AppTy isn't an arg, and this was causing a bad error message.
         I've changed it to use check_type on the left-hand side.
      
       - Some refactoring around when we print (TYPE blah) in error messages.
         The changes decrease the times when we do so, to good effect.
         Of course, this is still all controlled by
         -fprint-explicit-runtime-reps
      
      Fixes #14066 #14749
      
      Test cases: dependent/should_compile/{T14066a,T14749},
                  dependent/should_fail/T14066{,c,d,e,f,g,h}
      faec8d35
  4. 26 Mar, 2018 1 commit
    • alexvieth's avatar
      Fix performance of flattener patch (#12919) · b47a6c3a
      alexvieth authored
      This patch, authored by alexvieth and reviewed at D4451,
      makes performance improvements by critically optimizing parts
      of the flattener.
      
      Summary:
      T3064, T5321FD, T5321Fun, T9872a, T9872b, T9872c all pass.
      T9872a and T9872c show improvements beyond the -5% threshold.
      T9872d fails at 10.9% increased allocations.
      b47a6c3a
  5. 05 Mar, 2018 1 commit
    • Simon Peyton Jones's avatar
      Respect Note [The tcType invariant] · 3d252037
      Simon Peyton Jones authored
      I tried to do this with
      
          commit 0a12d92a
          Author: Simon Peyton Jones <simonpj@microsoft.com>
          Date:   Wed Dec 13 12:53:26 2017 +0000
      
          Further improvements to well-kinded types
      
          The typechecker has the invariant that every type should be well-kinded
          as it stands, without zonking.  See Note [The well-kinded type invariant]
          in TcType.
      
          That invariant was not being upheld, which led to Trac #14174.  I fixed
          part of it, but T14174a showed that there was more.  This patch finishes
          the job.
      
      But I didn't get it quite right as Trac #14873 showed.
      
      This patch fixes the problem; although I am still a bit unhappy.
      (See "A worry" in the HsApp case of tc_infer_hs_type.)
      3d252037
  6. 27 Feb, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix a nasty bug in the pure unifier · e99fdf77
      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.
      e99fdf77
  7. 13 Feb, 2018 1 commit
    • Tao He's avatar
      Raise parse error for `data T where`. · 8936ab69
      Tao He authored
      
      
      Empty GADTs data declarations can't be identified in type checker. This
      patch adds additional checks in parser and raise a parse error when
      encounter empty GADTs declarations but extension `GADTs` is not enabled.
      
      Only empty declarations are checked in parser to avoid affecting
      existing
      error messages related to missing GADTs extension.
      
      This patch should fix issue 8258.
      Signed-off-by: Tao He's avatarHE, Tao <sighingnow@gmail.com>
      
      Test Plan: make test TEST="T8258 T8258NoGADTs"
      
      Reviewers: bgamari, mpickering, alanz, RyanGlScott
      
      Reviewed By: bgamari, RyanGlScott
      
      Subscribers: adamse, RyanGlScott, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #8258
      
      Differential Revision: https://phabricator.haskell.org/D4350
      8936ab69
  8. 31 Jan, 2018 1 commit
    • Simon Peyton Jones's avatar
      Prioritise equalities when solving, incl deriveds · efba0546
      Simon Peyton Jones authored
      We already prioritise equalities when solving, but
      Trac #14723 showed that we were not doing so consistently
      enough, and as a result the type checker could go into a loop.
      Yikes.
      
      See Note [Prioritise equalities] in TcSMonad.
      
      Fixng this bug changed the solve order enough to demonstrate
      a problem with fundeps: Trac #14745.
      efba0546
  9. 26 Jan, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14719 by using the setting the right SrcSpan · 59fa7b32
      Ryan Scott authored
      Currently, error messages that germane to GADT constructors
      put the source span at only the first character in the constructor,
      leading to insufficient caret diagnostics. This can be easily fixed
      by using a source span that spans the entire constructor, instead of
      just the first character.
      
      Test Plan: make test TEST=T14719
      
      Reviewers: alanz, bgamari, simonpj
      
      Reviewed By: alanz, simonpj
      
      Subscribers: simonpj, goldfire, rwbarton, thomie, carter
      
      GHC Trac Issues: #14719
      
      Differential Revision: https://phabricator.haskell.org/D4344
      59fa7b32
  10. 18 Dec, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix scoping of pattern-synonym existentials · f1fe5b4a
      Simon Peyton Jones authored
      This patch fixes Trac #14998, where we eventually decided that
      the existential type variables of the signature of a pattern
      synonym should not scope over the pattern synonym.
      
      See Note [Pattern synonym existentials do not scope] in TcPatSyn.
      f1fe5b4a
  11. 15 Dec, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix tcDataKindSig · 68149452
      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.
      68149452
  12. 14 Dec, 2017 1 commit
  13. 13 Dec, 2017 3 commits
    • Simon Peyton Jones's avatar
      Further improvements to well-kinded types · 0a12d92a
      Simon Peyton Jones authored
      The typechecker has the invariant that every type should be well-kinded
      as it stands, without zonking.  See Note [The well-kinded type invariant]
      in TcType.
      
      That invariant was not being upheld, which led to Trac #14174.  I fixed
      part of it, but T14174a showed that there was more.  This patch finishes
      the job.
      
      * See Note [The tcType invariant] in TcHsType, which articulates an
        invariant that was very nearly, but not quite, true.  One place that
        falisified it was the HsWildCardTy case of tc_hs_type, so I fixed that.
      
      * mkNakedCastTy now makes no attempt to eliminate casts; indeed it cannot
        lest it break Note [The well-kinded type invariant].  The prior comment
        suggested that it was crucial for performance but happily it seems not
        to be. The extra Refls are eliminated by the zonker.
      
      * I found I could tidy up TcHsType.instantiateTyN and instantiateTyUntilN
        by eliminating one of its parameters.  That led to a cascade of minor
        improvements in TcTyClsDecls. Hooray.
      0a12d92a
    • Simon Peyton Jones's avatar
      Add missing stderr for Trac #14561 · aef4dee8
      Simon Peyton Jones authored
      aef4dee8
    • Simon Peyton Jones's avatar
      Detect levity-polymorphic uses of unsafeCoerce# · e40db7b1
      Simon Peyton Jones authored
      This bug was shown up by Trac #14561. The deguarer carefully
      detects unsaturated and levity-polymorphic uses of primops,
      but not of things like unsafeCoerce#.
      
      The fix is simple: see Note [Levity-polymorphic Ids] in Id.
      e40db7b1
  14. 11 Dec, 2017 2 commits
    • Simon Peyton Jones's avatar
      Fix SigTvs at the kind level · 8361b2c5
      Simon Peyton Jones authored
      This patch fixes two bugs in the treatment of SigTvs at the
      kind level:
      
      - We should always generalise them, never default them
        (Trac #14555, #14563)
      
      - We should check if they get unified with each other
        (Trac #11203)
      
      Both are described in TcHsType
         Note [Kind generalisation and SigTvs]
      8361b2c5
    • Simon Peyton Jones's avatar
      Build only well-kinded types in type checker · 8b36ed12
      Simon Peyton Jones authored
      During type inference, we maintain the invariant that every type is
      well-kinded /without/ zonking; and in particular that typeKind does
      not fail (as it can for ill-kinded types).
      
      But TcHsType.tcInferApps was not guaranteeing this invariant,
      resulting in Trac #14174 and #14520.
      
      This patch fixes it, making things better -- but it does /not/
      fix the program in Trac #14174 comment:5, which still crashes.
      So more work to be done.
      
      See Note [Ensure well-kinded types] in TcHsType
      8b36ed12
  15. 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
  16. 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
  17. 03 Oct, 2017 2 commits
    • Ryan Scott's avatar
      Track the order of user-written tyvars in DataCon · ef26182e
      Ryan Scott authored
      After typechecking a data constructor's type signature, its type
      variables are partitioned into two distinct groups: the universally
      quantified type variables and the existentially quantified type
      variables. Then, when prompted for the type of the data constructor,
      GHC gives this:
      
      ```lang=haskell
      MkT :: forall <univs> <exis>. (...)
      ```
      
      For H98-style datatypes, this is a fine thing to do. But for GADTs,
      this can sometimes produce undesired results with respect to
      `TypeApplications`. For instance, consider this datatype:
      
      ```lang=haskell
      data T a where
        MkT :: forall b a. b -> T a
      ```
      
      Here, the user clearly intended to have `b` be available for visible
      type application before `a`. That is, the user would expect
      `MkT @Int @Char` to be of type `Int -> T Char`, //not//
      `Char -> T Int`. But alas, up until now that was not how GHC
      operated—regardless of the order in which the user actually wrote
      the tyvars, GHC would give `MkT` the type:
      
      ```lang=haskell
      MkT :: forall a b. b -> T a
      ```
      
      Since `a` is universal and `b` is existential. This makes predicting
      what order to use for `TypeApplications` quite annoying, as
      demonstrated in #11721 and #13848.
      
      This patch cures the problem by tracking more carefully the order in
      which a user writes type variables in data constructor type
      signatures, either explicitly (with a `forall`) or implicitly
      (without a `forall`, in which case the order is inferred). This is
      accomplished by adding a new field `dcUserTyVars` to `DataCon`, which
      is a subset of `dcUnivTyVars` and `dcExTyVars` that is permuted to
      the order in which the user wrote them. For more details, refer to
      `Note [DataCon user type variables]` in `DataCon.hs`.
      
      An interesting consequence of this design is that more data
      constructors require wrappers. This is because the workers always
      expect the first arguments to be the universal tyvars followed by the
      existential tyvars, so when the user writes the tyvars in a different
      order, a wrapper type is needed to swizzle the tyvars around to match
      the order that the worker expects. For more details, refer to
      `Note [Data con wrappers and GADT syntax]` in `MkId.hs`.
      
      Test Plan: ./validate
      
      Reviewers: austin, goldfire, bgamari, simonpj
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: ezyang, goldfire, rwbarton, thomie
      
      GHC Trac Issues: #11721, #13848
      
      Differential Revision: https://phabricator.haskell.org/D3687
      ef26182e
    • Ryan Scott's avatar
      Add regression test for #9725 · a02039c7
      Ryan Scott authored
      Kind equalities saves the day!
      a02039c7
  18. 29 Sep, 2017 1 commit
  19. 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
  20. 13 Sep, 2017 1 commit
  21. 07 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Make Semigroup a superclass of Monoid (re #14191) · 8ae263ce
      Herbert Valerio Riedel authored
      Unfortunately, this requires introducing a couple of .hs-boot files to
      break up import cycles (mostly to provide class & typenames in order to
      be able to write type signatures).
      
      This does not yet re-export `(<>)` from Prelude (while the class-name
      `Semigroup` is reexported); that will happen in a future commit.
      
      Test Plan: local ./validate passed
      
      Reviewers: ekmett, austin, bgamari, erikd, RyanGlScott
      
      Reviewed By: ekmett, RyanGlScott
      
      GHC Trac Issues: #14191
      
      Differential Revision: https://phabricator.haskell.org/D3927
      8ae263ce
  22. 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
  23. 04 Sep, 2017 1 commit
  24. 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
  25. 18 Aug, 2017 1 commit
  26. 27 Jul, 2017 3 commits
    • Richard Eisenberg's avatar
      Track visibility in TypeEqOrigin · fb752133
      Richard Eisenberg authored
      A type equality error can arise from a mismatch between
      *invisible* arguments just as easily as from visible arguments.
      But we should really prefer printing out errors from visible
      arguments over invisible ones. Suppose we have a mismatch between
      `Proxy Int` and `Proxy Maybe`. Would you rather get an error
      between `Int` and `Maybe`? Or between `*` and `* -> *`? I thought
      so, too.
      
      There is a fair amount of plumbing with this one, but I think
      it's worth it.
      
      This commit introduces a performance regression in test
      perf/compiler/T5631. The cause of the regression is not the
      new visibility stuff, directly: it's due to a change from
      zipWithM to zipWith3M in TcUnify. To my surprise, zipWithM
      is nicely optimized (it fuses away), but zipWith3M is not.
      There are other examples of functions that could be made faster,
      so I've posted a separate ticket, #14037, to track these
      improvements. For now, I've accepted the small (6.6%) regression.
      fb752133
    • Richard Eisenberg's avatar
      Fix #13819 by refactoring TypeEqOrigin.uo_thing · c2417b87
      Richard Eisenberg authored
      The uo_thing field of TypeEqOrigin is used to track the
      "thing" (either term or type) that has the type (kind) stored
      in the TypeEqOrigin fields. Previously, this was sometimes a
      proper Core Type, which needed zonking and tidying. Now, it
      is only HsSyn: much simpler, and the error messages now use
      the user-written syntax.
      
      But this aspect of uo_thing didn't cause #13819; it was the
      sibling field uo_arity that did. uo_arity stored the number
      of arguments of uo_thing, useful when reporting something
      like "should have written 2 fewer arguments". We wouldn't want
      to say that if the thing didn't have two arguments. However,
      in practice, GHC was getting this wrong, and this message
      didn't seem all that helpful. Furthermore, the calculation
      of the number of arguments is what caused #13819 to fall over.
      This patch just removes uo_arity. In my opinion, the change
      to error messages is a nudge in the right direction.
      
      Test case: typecheck/should_fail/T13819
      c2417b87
    • Richard Eisenberg's avatar
      Improve error messages around kind mismatches. · 8e15e3d3
      Richard Eisenberg authored
      Previously, when canonicalizing (or unifying, in uType) a
      heterogeneous equality, we emitted a kind equality and used the
      resulting coercion to cast one side of the heterogeneous equality.
      
      While sound, this led to terrible error messages. (See the bugs
      listed below.) The problem is that using the coercion built from
      the emitted kind equality is a bit like a wanted rewriting a wanted.
      The solution is to keep heterogeneous equalities as irreducible.
      
      See Note [Equalities with incompatible kinds] in TcCanonical.
      
      This commit also removes a highly suspicious switch to FM_SubstOnly
      when flattening in the kinds of a type variable. I have no idea
      why this was there, other than as a holdover from pre-TypeInType.
      I've not left a Note because there is simply no reason I can conceive
      of that the FM_SubstOnly should be there.
      
      One challenge with this patch is that the emitted derived equalities
      might get emitted several times: when a heterogeneous equality is
      in an implication and then gets floated out from the implication,
      the Derived is present both in and out of the implication. This
      causes a duplicate error message. (Test case:
      typecheck/should_fail/T7368) Solution: track the provenance of
      Derived constraints and refuse to float out a constraint that has
      an insoluble Derived.
      
      Lastly, this labels one test (dependent/should_fail/RAE_T32a)
      as expect_broken, because the problem is really #12919. The
      different handling of constraints in this patch exposes the error.
      
      This fixes bugs #11198, #12373, #13530, and #13610.
      
      test cases:
      typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610}
      8e15e3d3
  27. 28 May, 2017 1 commit
  28. 26 May, 2017 1 commit
    • Simon Peyton Jones's avatar
      Some tidying up of type pretty-printing · ad14efd5
      Simon Peyton Jones authored
      Triggered by the changes in #13677, I ended up doing a bit of
      refactoring in type pretty-printing.
      
      * We were using TyOpPrec and FunPrec rather inconsitently, so
        I made it consisent.
      
      * That exposed the fact that we were a bit undecided about whether
        to print
           a + b -> c + d   vs   (a+b) -> (c+d)
        and similarly
           a ~ [b] => blah  vs   (a ~ [b]) => blah
      
        I decided to make TyOpPrec and FunPrec compare equal
        (in BasicTypes), so (->) is treated as equal precedence with
        other type operators, so you get the unambiguous forms above,
        even though they have more parens.
      
        We could readily reverse this decision.
        See Note [Type operator precedence] in BasicTypes
      
      * I fixed a bug in pretty-printing of HsType where some
        parens were omitted by mistake.
      ad14efd5
  29. 19 May, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix scoping of data cons during kind checking · 2501fb70
      Simon Peyton Jones authored
      Trac #13625 pointed out that in
      
         data X :: Y where Y :: X
      
      we need 'Y' to be in scope (as APromotionErr) when dealing with
      X's kind signature.  Previously we got a crash.
      
      This patch simplifies the code as well as making it work.
      2501fb70
  30. 09 May, 2017 1 commit
  31. 04 May, 2017 1 commit
    • Ryan Scott's avatar
      Add regression test for #11616 · 03ca391f
      Ryan Scott authored
      The code in #11616 has been working for a while (ever since 8.0.1),
      so let's add a regression test for it to put the nail in the coffin.
      
      Test Plan: make test TEST=T11616
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #11616
      
      Differential Revision: https://phabricator.haskell.org/D3531
      03ca391f
  32. 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
  33. 10 Mar, 2017 2 commits
    • Simon Peyton Jones's avatar
      Improve error messages for skolems · 48d1866e
      Simon Peyton Jones authored
      In error messages like this
          • Couldn't match type ‘c’ with ‘f0 (a -> b)’
            ‘c’ is a rigid type variable bound by
              the type signature for:
                f :: ((a -> b) -> b) -> forall c. c -> a
      
      we need to take case both to actually show that 'forall c',
      and to make sure that its name lines with the 'c' in the
      error message.
      
      This has been shaky for some time, and this commit puts it on solid
      ground.  See TcRnTypes: Note [SigSkol SkolemInfo]
      
      The main changes are
      
      * SigSkol gets an extra field that records the way in which the
        type signature was skolemised.
      
      * The type in SigSkol is now the /un/-skolemised version
      
      * pprSkolemInfo uses the info to make the tidy type line up
        nicely
      
      Lots of error message wibbles!
      48d1866e
    • 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