1. 11 Feb, 2020 1 commit
  2. 01 Feb, 2020 1 commit
    • Simon Peyton Jones's avatar
      Fix scoping of TyCon binders in TcTyClsDecls · 913287a0
      Simon Peyton Jones authored
      This patch fixes #17566 by refactoring the way we decide the final
      identity of the tyvars in the TyCons of a possibly-recursive nest
      of type and class decls, possibly with associated types.
      
      It's all laid out in
        Note [Swizzling the tyvars before generaliseTcTyCon]
      
      Main changes:
      
      * We have to generalise each decl (with its associated types)
        all at once: TcTyClsDecls.generaliseTyClDecl
      
      * The main new work is done in TcTyClsDecls.swizzleTcTyConBndrs
      
      * The mysterious TcHsSyn.zonkRecTyVarBndrs dies altogether
      
      Other smaller things:
      
      * A little refactoring, moving bindTyClTyVars from tcTyClDecl1
        to tcDataDefn, tcSynRhs, etc.  Clearer, reduces the number of
        parameters
      
      * Reduce the amount of swizzling required.
        Specifically, bindExplicitTKBndrs_Q_Tv doesn't need
          to clone a new Name for the TyVarTv, and not
          cloning means that in the vasly common case,
          swizzleTyConBndrs is a no-op
      
        In detail:
          Rename newTyVarTyVar --> cloneTyVarTyVar
          Add newTyVarTyTyVar that doesn't clone
          Use the non-cloning newTyVarTyVar in
             bindExplicitTKBndrs_Q_Tv
             Rename newFlexiKindedTyVarTyVar
                 --> cloneFlexiKindedTyVarTyVar
      
      * Define new utility function and use it
           HsDecls.familyDeclName ::
              FamilyDecl (GhcPass p) -> IdP (GhcPass p)
      
      Updates haddock submodule.
      913287a0
  3. 27 Jan, 2020 2 commits
    • Tom Ellis's avatar
      Disable two warnings for files that trigger them · 4bada77d
      Tom Ellis authored
      incomplete-uni-patterns and incomplete-record-updates will be in -Wall at a
      future date, so prepare for that by disabling those warnings on files that
      trigger them.
      4bada77d
    • Ryan Scott's avatar
      Use splitLHs{ForAll,Sigma}TyInvis throughout the codebase · 1132602f
      Ryan Scott authored
      Richard points out in #17688 that we use `splitLHsForAllTy` and
      `splitLHsSigmaTy` in places that we ought to be using the
      corresponding `-Invis` variants instead, identifying two bugs
      that are caused by this oversight:
      
      * Certain TH-quoted type signatures, such as those that appear in
        quoted `SPECIALISE` pragmas, silently turn visible `forall`s into
        invisible `forall`s.
      * When quoted, the type `forall a -> (a ~ a) => a` will turn into
        `forall a -> a` due to a bug in `DsMeta.repForall` that drops
        contexts that follow visible `forall`s.
      
      These are both ultimately caused by the fact that `splitLHsForAllTy`
      and `splitLHsSigmaTy` split apart visible `forall`s in addition to
      invisible ones. This patch cleans things up:
      
      * We now use `splitLHsForAllTyInvis` and `splitLHsSigmaTyInvis`
        throughout the codebase. Relatedly, the `splitLHsForAllTy` and
        `splitLHsSigmaTy` have been removed, as they are easy to misuse.
      * `DsMeta.repForall` now only handles invisible `forall`s to reduce
        the chance for confusion with visible `forall`s, which need to be
        handled differently. I also renamed it from `repForall` to
        `repForallT` to emphasize that its distinguishing characteristic
        is the fact that it desugars down to `L.H.TH.Syntax.ForallT`.
      
      Fixes #17688.
      1132602f
  4. 13 Jan, 2020 3 commits
  5. 08 Jan, 2020 1 commit
  6. 06 Jan, 2020 1 commit
  7. 11 Dec, 2019 2 commits
    • Richard Eisenberg's avatar
      Warn on inferred polymorphic recursion · 2d1b9619
      Richard Eisenberg authored
      Silly users sometimes try to use visible dependent quantification
      and polymorphic recursion without a CUSK or SAK. This causes
      unexpected errors. So we now adjust expectations with a bit
      of helpful messaging.
      
      Closes #17541 and closes #17131.
      
      test cases: dependent/should_fail/T{17541{,b},17131}
      2d1b9619
    • Ryan Scott's avatar
      Ignore unary constraint tuples during typechecking (#17511) · 921d3238
      Ryan Scott authored
      We deliberately avoid defining a magical `Unit%` class, for reasons
      that I have expounded upon in the newly added
      `Note [Ignore unary constraint tuples]` in `TcHsType`. However, a
      sneaky user could try to insert `Unit%` into their program by way of
      Template Haskell, leading to the interface-file error observed
      in #17511. To avoid this, any time we encounter a unary constraint
      tuple during typechecking, we drop the surrounding constraint tuple
      application. This is safe to do since `Unit% a` and `a` would be
      semantically equivalent (unlike other forms of unary tuples).
      
      Fixes #17511.
      921d3238
  8. 30 Nov, 2019 1 commit
  9. 28 Nov, 2019 1 commit
  10. 13 Nov, 2019 1 commit
    • Ben Gamari's avatar
      Ensure that coreView/tcView are able to inline · 2d4f9ad8
      Ben Gamari authored
      Previously an import cycle between Type and TyCoRep meant that several
      functions in TyCoRep ended up SOURCE import coreView. This is quite
      unfortunate as coreView is intended to be fused into a larger pattern
      match and not incur an extra call.
      
      Fix this with a bit of restructuring:
      
       * Move the functions in `TyCoRep` which depend upon things in `Type`
         into `Type`
       * Fold contents of `Kind` into `Type` and turn `Kind` into a simple
         wrapper re-exporting kind-ish things from `Type`
       * Clean up the redundant imports that popped up as a result
      
      Closes #17441.
      
      Metric Decrease:
          T4334
      2d4f9ad8
  11. 17 Oct, 2019 1 commit
  12. 16 Oct, 2019 1 commit
    • Richard Eisenberg's avatar
      Break up TcRnTypes, among other modules. · 51fad9e6
      Richard Eisenberg authored
      This introduces three new modules:
      
       - basicTypes/Predicate.hs describes predicates, moving
         this logic out of Type. Predicates don't really exist
         in Core, and so don't belong in Type.
      
       - typecheck/TcOrigin.hs describes the origin of constraints
         and types. It was easy to remove from other modules and
         can often be imported instead of other, scarier modules.
      
       - typecheck/Constraint.hs describes constraints as used in
         the solver. It is taken from TcRnTypes.
      
      No work other than module splitting is in this patch.
      
      This is the first step toward homogeneous equality, which will
      rely more strongly on predicates. And homogeneous equality is the
      next step toward a dependently typed core language.
      51fad9e6
  13. 25 Sep, 2019 1 commit
    • Vladislav Zavialov's avatar
      Standalone kind signatures (#16794) · 0b5eede9
      Vladislav Zavialov authored
      Implements GHC Proposal #54: .../ghc-proposals/blob/master/proposals/0054-kind-signatures.rst
      
      With this patch, a type constructor can now be given an explicit
      standalone kind signature:
      
        {-# LANGUAGE StandaloneKindSignatures #-}
        type Functor :: (Type -> Type) -> Constraint
        class Functor f where
          fmap :: (a -> b) -> f a -> f b
      
      This is a replacement for CUSKs (complete user-specified
      kind signatures), which are now scheduled for deprecation.
      
      User-facing changes
      -------------------
      
      * A new extension flag has been added, -XStandaloneKindSignatures, which
        implies -XNoCUSKs.
      
      * There is a new syntactic construct, a standalone kind signature:
      
          type <name> :: <kind>
      
        Declarations of data types, classes, data families, type families, and
        type synonyms may be accompanied by a standalone kind signature.
      
      * A standalone kind signature enables polymorphic recursion in types,
        just like a function type signature enables polymorphic recursion in
        terms. This obviates the need for CUSKs.
      
      * TemplateHaskell AST has been extended with 'KiSigD' to represent
        standalone kind signatures.
      
      * GHCi :info command now prints the kind signature of type constructors:
      
          ghci> :info Functor
          type Functor :: (Type -> Type) -> Constraint
          ...
      
      Limitations
      -----------
      
      * 'forall'-bound type variables of a standalone kind signature do not
        scope over the declaration body, even if the -XScopedTypeVariables is
        enabled. See #16635 and #16734.
      
      * Wildcards are not allowed in standalone kind signatures, as partial
        signatures do not allow for polymorphic recursion.
      
      * Associated types may not be given an explicit standalone kind
        signature. Instead, they are assumed to have a CUSK if the parent class
        has a standalone kind signature and regardless of the -XCUSKs flag.
      
      * Standalone kind signatures do not support multiple names at the moment:
      
          type T1, T2 :: Type -> Type   -- rejected
          type T1 = Maybe
          type T2 = Either String
      
        See #16754.
      
      * Creative use of equality constraints in standalone kind signatures may
        lead to GHC panics:
      
          type C :: forall (a :: Type) -> a ~ Int => Constraint
          class C a where
            f :: C a => a -> Int
      
        See #16758.
      
      Implementation notes
      --------------------
      
      * The heart of this patch is the 'kcDeclHeader' function, which is used to
        kind-check a declaration header against its standalone kind signature.
        It does so in two rounds:
      
          1. check user-written binders
          2. instantiate invisible binders a la 'checkExpectedKind'
      
      * 'kcTyClGroup' now partitions declarations into declarations with a
        standalone kind signature or a CUSK (kinded_decls) and declarations
        without either (kindless_decls):
      
          * 'kinded_decls' are kind-checked with 'checkInitialKinds'
          * 'kindless_decls' are kind-checked with 'getInitialKinds'
      
      * DerivInfo has been extended with a new field:
      
          di_scoped_tvs :: ![(Name,TyVar)]
      
        These variables must be added to the context in case the deriving clause
        references tcTyConScopedTyVars. See #16731.
      0b5eede9
  14. 20 Sep, 2019 1 commit
  15. 19 Sep, 2019 2 commits
    • Richard Eisenberg's avatar
      Use level numbers for generalisation · f594a68a
      Richard Eisenberg authored
      This fixes #15809, and is covered in
      Note [Use level numbers for quantification] in TcMType.
      
      This patch removes the "global tyvars" from the
      environment, a nice little win.
      f594a68a
    • Richard Eisenberg's avatar
      Refactor kindGeneralize and friends · d9c6b86e
      Richard Eisenberg authored
      This commit should have no change in behavior.(*)
      
      The observation was that Note [Recipe for checking a signature]
      says that every metavariable in a type-checked type must either
        (A) be generalized
        (B) be promoted
        (C) be zapped.
      Yet the code paths for doing these were all somewhat separate.
      This led to some steps being skipped. This commit shores this
      all up. The key innovation is TcHsType.kindGeneralizeSome, with
      appropriate commentary.
      
      This commit also sets the stage for #15809, by turning the
      WARNing about bad level-numbers in generalisation into an
      ASSERTion. The actual fix for #15809 will be in a separate
      commit.
      
      Other changes:
       * zonkPromoteType is now replaced by kindGeneralizeNone.
         This might have a small performance degradation, because
         zonkPromoteType zonked and promoted all at once. The new
         code path promotes first, and then zonks.
      
       * A call to kindGeneralizeNone was added in tcHsPartialSigType.
         I think this was a lurking bug, because it did not follow
         Note [Recipe for checking a signature]. I did not try to
         come up with an example showing the bug. This is the (*)
         above.
      
         Because of this change, there is an error message regression
         in partial-sigs/should_fail/T14040a. This problem isn't really
         a direct result of this refactoring, but is a symptom of
         something deeper. See #16775, which addresses the deeper
         problem.
      
       * I added a short-cut to quantifyTyVars, in case there's
         nothing to quantify.
      
       * There was a horribly-outdated Note that wasn't referred
         to. Gone now.
      
       * While poking around with T14040a, I discovered a small
         mistake in the Coercion.simplifyArgsWorker. Easy to fix,
         happily.
      
       * See new Note [Free vars in coercion hole] in TcMType.
         Previously, we were doing the wrong thing when looking
         at a coercion hole in the gather-candidates algorithm.
         Fixed now, with lengthy explanation.
      
      Metric Decrease:
        T14683
      d9c6b86e
  16. 02 Aug, 2019 1 commit
    • Ryan Scott's avatar
      Rip out 9-year-old pattern variable hack (#17007) · 1b9d32b8
      Ryan Scott authored
      GHC had an ad hoc validity check in place to rule out pattern
      variables bound by type synonyms, such as in the following example:
      
      ```hs
      type ItemColID a b = Int  -- Discards a,b
      
      get :: ItemColID a b -> ItemColID a b
      get (x :: ItemColID a b) = x :: ItemColID a b
      ```
      
      This hack is wholly unnecessary nowadays, since OutsideIn(X) is more
      than capable of instantiating `a` and `b` to `Any`. In light of this,
      let's rip out this validity check.
      
      Fixes #17007.
      1b9d32b8
  17. 11 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Don't typecheck too much (or too little) in DerivingVia (#16923) · b507aceb
      Ryan Scott authored
      Previously, GHC would typecheck the `via` type once per class in a
      `deriving` clause, which caused the problems observed in #16923.
      This patch restructures some of the functionality in `TcDeriv` and
      `TcHsType` to avoid this problem. We now typecheck the `via` type
      exactly once per `deriving` clause and *then* typecheck all of the
      classes in the clause.
      See `Note [Don't typecheck too much in DerivingVia]` in `TcDeriv`
      for the full details.
      b507aceb
  18. 09 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Use an empty data type in TTG extension constructors (#15247) · 6a03d77b
      Ryan Scott authored
      To avoid having to `panic` any time a TTG extension constructor is
      consumed, this MR introduces an uninhabited 'NoExtCon' type and uses
      that in every extension constructor's type family instance where it
      is appropriate. This also introduces a 'noExtCon' function which
      eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates
      a 'Void'.
      
      I also renamed the existing `NoExt` type to `NoExtField` to better
      distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of
      code churn resulting from this.
      
      Bumps the Haddock submodule. Fixes #15247.
      6a03d77b
  19. 05 Jul, 2019 1 commit
  20. 23 Jun, 2019 1 commit
    • Ryan Scott's avatar
      Refactor UnliftedNewtypes-relation kind signature validity checks · 9bbcc3be
      Ryan Scott authored
      This fixes three infelicities related to the programs that are
      (and aren't) accepted with `UnliftedNewtypes`:
      
      * Enabling `UnliftedNewtypes` would permit newtypes to have return
        kind `Id Type`, which had disastrous results (i.e., GHC panics).
      * Data family declarations ending in kind `TYPE r` (for some `r`)
        weren't being accepted if `UnliftedNewtypes` wasn't enabled,
        despite the GHC proposal specifying otherwise.
      * GHC wasn't warning about programs that _would_ typecheck if
        `UnliftedNewtypes` were enabled in certain common cases.
      
      As part of fixing these issues, I factored out the logic for checking
      all of the various properties about data type/data family return
      kinds into a single `checkDataKindSig` function. I also cleaned up
      some of the formatting in the existing error message that gets
      thrown.
      
      Fixes #16821, fixes #16827, and fixes #16829.
      9bbcc3be
  21. 20 Jun, 2019 1 commit
    • Simon Peyton Jones's avatar
      Fix typechecking of partial type signatures · 48fb3482
      Simon Peyton Jones authored
      Partial type sigs had grown hair.  tcHsParialSigType was
      doing lots of unnecessary work, and tcInstSig was cloning it
      unnecessarily -- and the result didn't even work: #16728.
      
      This patch cleans it all up, described by TcHsType
        Note [Checking parital type signatures]
      
      I basically just deleted code... but very carefully!
      
      Some refactoring along the way
      
      * Distinguish more explicintly between "anonymous" wildcards "_"
        and "named" wildcards "_a".  I changed the names of a number
        of functions to make this distinction much more apparent.
      
      The patch also revealed that the code in `TcExpr`
      that implements the special typing rule for `($)` was wrong.
      It called `getRuntimeRep` in a situation where where was no
      particular reason to suppose that the thing had kind `TYPE r`.
      
      This caused a crash in typecheck/should_run/T10846.
      
      The fix was easy, and actually simplifies the code in `TcExpr`
      quite a bit.  Hooray.
      48fb3482
  22. 14 Jun, 2019 1 commit
    • Andrew Martin's avatar
      Implement the -XUnliftedNewtypes extension. · effdd948
      Andrew Martin authored
      GHC Proposal: 0013-unlifted-newtypes.rst
      Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/98
      Issues: #15219, #1311, #13595, #15883
      Implementation Details:
        Note [Implementation of UnliftedNewtypes]
        Note [Unifying data family kinds]
        Note [Compulsory newtype unfolding]
      
      This patch introduces the -XUnliftedNewtypes extension. When this
      extension is enabled, GHC drops the restriction that the field in
      a newtype must be of kind (TYPE 'LiftedRep). This allows types
      like Int# and ByteArray# to be used in a newtype. Additionally,
      coerce is made levity-polymorphic so that it can be used with
      newtypes over unlifted types.
      
      The bulk of the changes are in TcTyClsDecls.hs. With -XUnliftedNewtypes,
      getInitialKind is more liberal, introducing a unification variable to
      return the kind (TYPE r0) rather than just returning (TYPE 'LiftedRep).
      When kind-checking a data constructor with kcConDecl, we attempt to
      unify the kind of a newtype with the kind of its field's type. When
      typechecking a data declaration with tcTyClDecl, we again perform a
      unification. See the implementation note for more on this.
      Co-authored-by: Richard Eisenberg's avatarRichard Eisenberg <rae@richarde.dev>
      effdd948
  23. 09 Jun, 2019 1 commit
    • Richard Eisenberg's avatar
      Fix #16517 by bumping the TcLevel for method sigs · a22e51ea
      Richard Eisenberg authored
      There were actually two bugs fixed here:
      
      1. candidateQTyVarsOfType needs to be careful that it does not
         try to zap metavariables from an outer scope as "naughty"
         quantification candidates. This commit adds a simple check
         to avoid doing so.
      
      2. We weren't bumping the TcLevel in kcHsKindSig, which was used
         only for class method sigs. This mistake led to the acceptance
         of
      
           class C a where
             meth :: forall k. Proxy (a :: k) -> ()
      
         Note that k is *locally* quantified. This patch fixes the
         problem by using tcClassSigType, which correctly bumps the
         level. It's a bit inefficient because tcClassSigType does other
         work, too, but it would be tedious to repeat much of the code
         there with only a few changes. This version works well and is
         simple.
      
      And, while updating comments, etc., I noticed that tcRnType was
      missing a pushTcLevel, leading to #16767, which this patch also
      fixes, by bumping the level. In the refactoring here, I also
      use solveEqualities. This initially failed ghci/scripts/T15415,
      but that was fixed by teaching solveEqualities to respect
      -XPartialTypeSignatures.
      
      This patch also cleans up some Notes around error generation that
      came up in conversation.
      
      Test case: typecheck/should_fail/T16517, ghci/scripts/T16767
      a22e51ea
  24. 03 May, 2019 1 commit
    • Ryan Scott's avatar
      Make equality constraints in kinds invisible · cc495d57
      Ryan Scott authored
      Issues #12102 and #15872 revealed something strange about the way GHC
      handles equality constraints in kinds: it treats them as _visible_
      arguments! This causes a litany of strange effects, from strange
      error messages
      (ghc/ghc#12102 (comment 169035))
      to bizarre `Eq#`-related things leaking through to GHCi output, even
      without any special flags enabled.
      
      This patch is an attempt to contain some of this strangeness.
      In particular:
      
      * In `TcHsType.etaExpandAlgTyCon`, we propagate through the
        `AnonArgFlag`s of any `Anon` binders. Previously, we were always
        hard-coding them to `VisArg`, which meant that invisible binders
        (like those whose kinds were equality constraint) would mistakenly
        get flagged as visible.
      * In `ToIface.toIfaceAppArgsX`, we previously assumed that the
        argument to a `FunTy` always corresponding to a `Required`
        argument. We now dispatch on the `FunTy`'s `AnonArgFlag` and map
        `VisArg` to `Required` and `InvisArg` to `Inferred`. As a
        consequence, the iface pretty-printer correctly recognizes that
        equality coercions are inferred arguments, and as a result,
        only displays them in `-fprint-explicit-kinds` is enabled.
      * Speaking of iface pretty-printing, `Anon InvisArg` binders were
        previously being pretty-printed like `T (a :: b ~ c)`, as if they
        were required. This seemed inconsistent with other invisible
        arguments (that are printed like `T @{d}`), so I decided to switch
        this to `T @{a :: b ~ c}`.
      
      Along the way, I also cleaned up a minor inaccuracy in the users'
      guide section for constraints in kinds that was spotted in
      ghc/ghc#12102 (comment 136220).
      
      Fixes #12102 and #15872.
      cc495d57
  25. 20 Mar, 2019 1 commit
  26. 16 Mar, 2019 1 commit
  27. 15 Mar, 2019 1 commit
  28. 09 Mar, 2019 1 commit
    • Simon Peyton Jones's avatar
      Stop inferring over-polymorphic kinds · 1f5cc9dc
      Simon Peyton Jones authored
      Before this patch GHC was trying to be too clever
      (Trac #16344); it succeeded in kind-checking this
      polymorphic-recursive declaration
      
          data T ka (a::ka) b
            = MkT (T Type           Int   Bool)
                  (T (Type -> Type) Maybe Bool)
      
      As Note [No polymorphic recursion] discusses, the "solution" was
      horribly fragile.  So this patch deletes the key lines in
      TcHsType, and a wodge of supporting stuff in the renamer.
      
      There were two regressions, both the same: a closed type family
      decl like this (T12785b) does not have a CUSK:
        type family Payload (n :: Peano) (s :: HTree n x) where
          Payload Z (Point a) = a
          Payload (S n) (a `Branch` stru) = a
      
      To kind-check the equations we need a dependent kind for
      Payload, and we don't get that any more.  Solution: make it
      a CUSK by giving the result kind -- probably a good thing anyway.
      
      The other case (T12442) was very similar: a close type family
      declaration without a CUSK.
      1f5cc9dc
  29. 05 Mar, 2019 1 commit
    • Simon Peyton Jones's avatar
      Be more careful when naming TyCon binders · 80dfcee6
      Simon Peyton Jones authored
      This patch fixes two rather gnarly test cases:
        * Trac #16342 (mutual recursion)
          See Note [Tricky scoping in generaliseTcTyCon]
      
        * Trac #16221 (shadowing)
          See Note [Unification variables need fresh Names]
      
      The main changes are:
      
      * Substantial reworking of TcTyClsDecls.generaliseTcTyCon
        This is the big change, and involves the rather tricky
        function TcHsSyn.zonkRecTyVarBndrs.
      
        See Note [Inferring kinds for type declarations] and
        Note [Tricky scoping in generaliseTcTyCon] for the details.
      
      * bindExplicitTKBndrs_Tv and bindImplicitTKBndrs_Tv both now
        allocate /freshly-named/ unification variables. Indeed, more
        generally, unification variables are always fresh; see
        Note [Unification variables need fresh Names] in TcMType
      
      * Clarify the role of tcTyConScopedTyVars.
        See Note [Scoped tyvars in a TcTyCon] in TyCon
      
      As usual, this dragged in some more refactoring:
      
      * Renamed TcMType.zonkTyCoVarBndr to zonkAndSkolemise
      
      * I renamed checkValidTelescope to checkTyConTelescope;
        it's only used on TyCons, and indeed takes a TyCon as argument.
      
      * I folded the slightly-mysterious reportFloatingKvs into
        checkTyConTelescope. (Previously all its calls immediately
        followed a call to checkTyConTelescope.)  It makes much more
        sense there.
      
      * I inlined some called-once functions to simplify
        checkValidTyFamEqn. It's less spaghetti-like now.
      
      * This patch also fixes Trac #16251.  I'm not quite sure why #16251
        went wrong in the first place, nor how this patch fixes it, but
        hey, it's good, and life is short.
      80dfcee6
  30. 01 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Visible dependent quantification · c26d299d
      Ryan Scott authored
      This implements GHC proposal 35
      (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst)
      by adding the ability to write kinds with
      visible dependent quantification (VDQ).
      
      Most of the work for supporting VDQ was actually done _before_ this
      patch. That is, GHC has been able to reason about kinds with VDQ for
      some time, but it lacked the ability to let programmers directly
      write these kinds in the source syntax. This patch is primarly about
      exposing this ability, by:
      
      * Changing `HsForAllTy` to add an additional field of type
        `ForallVisFlag` to distinguish between invisible `forall`s (i.e,
        with dots) and visible `forall`s (i.e., with arrows)
      * Changing `Parser.y` accordingly
      
      The rest of the patch mostly concerns adding validity checking to
      ensure that VDQ is never used in the type of a term (as permitting
      this would require full-spectrum dependent types). This is
      accomplished by:
      
      * Adding a `vdqAllowed` predicate to `TcValidity`.
      * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy`
        that only splits invisible `forall`s. This function is used in
        certain places (e.g., in instance declarations) to ensure that GHC
        doesn't try to split visible `forall`s (e.g., if it tried splitting
        `instance forall a -> Show (Blah a)`, then GHC would mistakenly
        allow that declaration!)
      
      This also updates Template Haskell by introducing a new `ForallVisT`
      constructor to `Type`.
      
      Fixes #16326. Also fixes #15658 by documenting this feature in the
      users' guide.
      c26d299d
  31. 27 Feb, 2019 1 commit
    • Vladislav Zavialov's avatar
      Treat kind/type variables identically, demolish FKTV · 5bc195b1
      Vladislav Zavialov authored
      Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst
      Fixes Trac #16334, Trac #16315
      
      With this patch, scoping rules for type and kind variables have been
      unified: kind variables no longer receieve special treatment. This
      simplifies both the language and the implementation.
      
      User-facing changes
      -------------------
      
      * Kind variables are no longer implicitly quantified when an explicit
        forall is used:
      
          p ::             Proxy (a :: k)    -- still accepted
          p :: forall k a. Proxy (a :: k)    -- still accepted
          p :: forall   a. Proxy (a :: k)    -- no longer accepted
      
        In other words, now we adhere to the "forall-or-nothing" rule more
        strictly.
      
        Related function: RnTypes.rnImplicitBndrs
      
      * The -Wimplicit-kind-vars warning has been deprecated.
      
      * Kind variables are no longer implicitly quantified in constructor
        declarations:
      
          data T a        = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- no longer accepted
          data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- still accepted
      
        Related function: RnTypes.extractRdrKindSigVars
      
      * Implicitly quantified kind variables are no longer put in front of
        other variables:
      
          f :: Proxy (a :: k) -> Proxy (b :: j)
      
          f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b   -- old order
          f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b   -- new order
      
        This is a breaking change for users of TypeApplications. Note that
        we still respect the dpendency order: 'k' before 'a', 'j' before 'b'.
        See "Ordering of specified variables" in the User's Guide.
      
        Related function: RnTypes.rnImplicitBndrs
      
      * In type synonyms and type family equations, free variables on the RHS
        are no longer implicitly quantified unless used in an outermost kind
        annotation:
      
          type T = Just (Nothing :: Maybe a)         -- no longer accepted
          type T = Just Nothing :: Maybe (Maybe a)   -- still accepted
      
        The latter form is a workaround due to temporary lack of an explicit
        quantification method. Ideally, we would write something along these
        lines:
      
          type T @a = Just (Nothing :: Maybe a)
      
        Related function: RnTypes.extractHsTyRdrTyVarsKindVars
      
      * Named wildcards in kinds are fixed (Trac #16334):
      
          x :: (Int :: _t)    -- this compiles, infers (_t ~ Type)
      
        Related function: RnTypes.partition_nwcs
      
      Implementation notes
      --------------------
      
      * One of the key changes is the removal of FKTV in RnTypes:
      
        - data FreeKiTyVars = FKTV { fktv_kis    :: [Located RdrName]
        -                          , fktv_tys    :: [Located RdrName] }
        + type FreeKiTyVars = [Located RdrName]
      
        We used to keep track of type and kind variables separately, but
        now that they are on equal footing when it comes to scoping, we
        can put them in the same list.
      
      * extract_lty and family are no longer parametrized by TypeOrKind,
        as we now do not distinguish kind variables from type variables.
      
      * PatSynExPE and the related Note [Pattern synonym existentials do not scope]
        have been removed (Trac #16315). With no implicit kind quantification,
        we can no longer trigger the error.
      
      * reportFloatingKvs and the related Note [Free-floating kind vars]
        have been removed. With no implicit kind quantification,
        we can no longer trigger the error.
      5bc195b1
  32. 24 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Add AnonArgFlag to FunTy · 6cce36f8
      Simon Peyton Jones authored
      The big payload of this patch is:
      
        Add an AnonArgFlag to the FunTy constructor
        of Type, so that
          (FunTy VisArg   t1 t2) means (t1 -> t2)
          (FunTy InvisArg t1 t2) means (t1 => t2)
      
      The big payoff is that we have a simple, local test to make
      when decomposing a type, leading to many fewer calls to
      isPredTy. To me the code seems a lot tidier, and probably
      more efficient (isPredTy has to take the kind of the type).
      
      See Note [Function types] in TyCoRep.
      
      There are lots of consequences
      
      * I made FunTy into a record, so that it'll be easier
        when we add a linearity field, something that is coming
        down the road.
      
      * Lots of code gets touched in a routine way, simply because it
        pattern matches on FunTy.
      
      * I wanted to make a pattern synonym for (FunTy2 arg res), which
        picks out just the argument and result type from the record. But
        alas the pattern-match overlap checker has a heart attack, and
        either reports false positives, or takes too long.  In the end
        I gave up on pattern synonyms.
      
        There's some commented-out code in TyCoRep that shows what I
        wanted to do.
      
      * Much more clarity about predicate types, constraint types
        and (in particular) equality constraints in kinds.  See TyCoRep
        Note [Types for coercions, predicates, and evidence]
        and Note [Constraints in kinds].
      
        This made me realise that we need an AnonArgFlag on
        AnonTCB in a TyConBinder, something that was really plain
        wrong before. See TyCon Note [AnonTCB InivsArg]
      
      * When building function types we must know whether we
        need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
        This turned out to be pretty easy in practice.
      
      * Pretty-printing of types, esp in IfaceType, gets
        tidier, because we were already recording the (->)
        vs (=>) distinction in an ad-hoc way.  Death to
        IfaceFunTy.
      
      * mkLamType needs to keep track of whether it is building
        (t1 -> t2) or (t1 => t2).  See Type
        Note [mkLamType: dictionary arguments]
      
      Other minor stuff
      
      * Some tidy-up in validity checking involving constraints;
        Trac #16263
      6cce36f8
  33. 22 Feb, 2019 1 commit
  34. 18 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Get rid of tcm_smart from TyCoMapper · 1f1b9e35
      Simon Peyton Jones authored
      Following a succession of refactorings of the type checker,
      culminating in the patch
             Make a smart mkAppTyM
      we have got rid of mkNakedAppTy etc.  And that in turn
      meant that the tcm_smart field of the generic TyCoMapper
      (in Type.hs) was entirely unused.  It was always set to True.
      
      So this patch just gets rid of it completely.  Less code,
      less complexity, and more efficient because fewer higher-order
      function calls.  Everyone wins.
      
      No change in behaviour; this does not cure any bugs!
      1f1b9e35
  35. 14 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Fail fast in solveLocalEqualities · 5c1f268e
      Simon Peyton Jones authored
      This patch makes us fail fast in TcSimplify.solveLocalEqualities,
      and in TcHsType.tc_hs_sig_type, if there are insoluble constraints.
      
      Previously we ploughed on even if there were insoluble constraints,
      leading to a cascade of hard-to-understand type errors. Failing
      eagerly is much better; hence a lot of testsuite error message
      changes.  Eg if we have
                f :: [Maybe] -> blah
                f xs = e
      then trying typecheck 'f x = e' with an utterly bogus type
      is just asking for trouble.
      
      I can't quite remember what provoked me to make this change,
      but I think the error messages are notably improved, by
      removing confusing clutter and focusing on the real error.
      5c1f268e