1. 17 Jun, 2020 1 commit
    • Krzysztof Gogolewski's avatar
      Linear types (#15981) · 40fa237e
      Krzysztof Gogolewski authored and Ben Gamari's avatar Ben Gamari committed
      This is the first step towards implementation of the linear types proposal
      It features
      * A language extension -XLinearTypes
      * Syntax for linear functions in the surface language
      * Linearity checking in Core Lint, enabled with -dlinear-core-lint
      * Core-to-core passes are mostly compatible with linearity
      * Fields in a data type can be linear or unrestricted; linear fields
        have multiplicity-polymorphic constructors.
        If -XLinearTypes is disabled, the GADT syntax defaults to linear fields
      The following items are not yet supported:
      * a # m -> b syntax (only prefix FUN is supported for now)
      * Full multiplicity inference (multiplicities are really only checked)
      * Decent linearity error messages
      * Linear let, where, and case expressions in the surface language
        (each of these currently introduce the unrestricted variant)
      * Multiplicity-parametric fields
      * Syntax for annotating lambda-bound or let-bound with a multiplicity
      * Syntax for non-linear/multiple-field-multiplicity records
      * Linear projections for records with a single linear field
      * Linear pattern synonyms
      * Multiplicity coercions (test LinearPolyType)
      A high-level description can be found at
      Following the link above you will find a description of the changes made to Core.
      This commit has been authored by
      * Richard Eisenberg
      * Krzysztof Gogolewski
      * Matthew Pickering
      * Arnaud Spiwack
      With contributions from:
      * Mark Barbone
      * Alexander Vershilov
      Updates haddock submodule.
  2. 13 Jun, 2020 1 commit
    • Ryan Scott's avatar
      Use HsForAllTelescope to avoid inferred, visible foralls · a31218f7
      Ryan Scott authored and Ben Gamari's avatar Ben Gamari committed
      Currently, `HsForAllTy` permits the combination of `ForallVis` and
      `Inferred`, but you can't actually typecheck code that uses it
      (e.g., `forall {a} ->`). This patch refactors `HsForAllTy` to use a
      new `HsForAllTelescope` data type that makes a type-level distinction
      between visible and invisible `forall`s such that visible `forall`s
      do not track `Specificity`. That part of the patch is actually quite
      small; the rest is simply changing consumers of `HsType` to
      accommodate this new type.
      Fixes #18235. Bumps the `haddock` submodule.
  3. 10 Jun, 2020 1 commit
    • Ryan Scott's avatar
      Always use rnImplicitBndrs to bring implicit tyvars into scope · a47e6442
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      This implements a first step towards #16762 by changing the renamer
      to always use `rnImplicitBndrs` to bring implicitly bound type
      variables into scope. The main change is in `rnFamInstEqn` and
      `bindHsQTyVars`, which previously used _ad hoc_ methods of binding
      their implicit tyvars.
      There are a number of knock-on consequences:
      * One of the reasons that `rnFamInstEqn` used an _ad hoc_ binding
        mechanism was to give more precise source locations in
        `-Wunused-type-patterns` warnings. (See
        #16762 (comment 273343) for an
        example of this.) However, these warnings are actually a little
        _too_ precise, since implicitly bound type variables don't have
        exact binding sites like explicitly bound type variables do.
        A similar problem existed for
        "`Different names for the same type variable`" errors involving
        implicit tyvars bound by `bindHsQTyVars`.
        Therefore, we simply accept the less precise (but more accurate)
        source locations from `rnImplicitBndrs` in `rnFamInstEqn` and
        `bindHsQTyVars`. See
        `Note [Source locations for implicitly bound type variables]` in
        `GHC.Rename.HsType` for the full story.
      * In order for `rnImplicitBndrs` to work in `rnFamInstEqn`, it needs
        to be able to look up names from the parent class (in the event
        that we are renaming an associated type family instance). As a
        result, `rnImplicitBndrs` now takes an argument of type
        `Maybe assoc`, which is `Just` in the event that a type family
        instance is associated with a class.
      * Previously, GHC kept track of three type synonyms for free type
        variables in the renamer: `FreeKiTyVars`, `FreeKiTyVarsDups`
        (which are allowed to contain duplicates), and
        `FreeKiTyVarsNoDups` (which contain no duplicates). However, making
        is a distinction between `-Dups` and `-NoDups` is now pointless, as
        all code that returns `FreeKiTyVars{,Dups,NoDups}` will eventually
        end up being passed to `rnImplicitBndrs`, which removes duplicates.
        As a result, I decided to just get rid of `FreeKiTyVarsDups` and
        `FreeKiTyVarsNoDups`, leaving only `FreeKiTyVars`.
      * The `bindLRdrNames` and `deleteBys` functions are now dead code, so
        I took the liberty of removing them.
  4. 09 Jun, 2020 1 commit
    • Ryan Scott's avatar
      Make GADT constructors adhere to the forall-or-nothing rule properly · 72c7fe9a
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      Issue #18191 revealed that the types of GADT constructors don't quite
      adhere to the `forall`-or-nothing rule. This patch serves to clean up
      this sad state of affairs somewhat. The main change is not in the
      code itself, but in the documentation, as this patch introduces two
      sections to the GHC User's Guide:
      * A "Formal syntax for GADTs" section that presents a BNF-style
        grammar for what is and isn't allowed in GADT constructor types.
        This mostly exists to codify GHC's existing behavior, but it also
        imposes a new restriction that addresses #18191: the outermost
        `forall` and/or context in a GADT constructor is not allowed to be
        surrounded by parentheses. Doing so would make these
        `forall`s/contexts nested, and GADTs do not support nested
        `forall`s/contexts at present.
      * A "`forall`-or-nothing rule" section that describes exactly what
        the `forall`-or-nothing rule is all about. Surprisingly, there was
        no mention of this anywhere in the User's Guide up until now!
      To adhere the new specification in the "Formal syntax for GADTs"
      section of the User's Guide, the following code changes were made:
      * A new function, `GHC.Hs.Type.splitLHsGADTPrefixTy`, was introduced.
        This is very much like `splitLHsSigmaTy`, except that it avoids
        splitting apart any parentheses, which can be syntactically
        significant for GADT types. See
        `Note [No nested foralls or contexts in GADT constructors]` in
      * `ConDeclGADTPrefixPs`, an extension constructor for `XConDecl`, was
        introduced so that `GHC.Parser.PostProcess.mkGadtDecl` can return
        it when given a prefix GADT constructor. Unlike `ConDeclGADT`,
        `ConDeclGADTPrefixPs` does not split the GADT type into its argument
        and result types, as this cannot be done until after the type is
        renamed (see `Note [GADT abstract syntax]` in `GHC.Hs.Decls` for why
        this is the case).
      * `GHC.Renamer.Module.rnConDecl` now has an additional case for
        `ConDeclGADTPrefixPs` that (1) splits apart the full `LHsType` into
        its `forall`s, context, argument types, and result type, and
        (2) checks for nested `forall`s/contexts. Step (2) used to be
        performed the typechecker (in `GHC.Tc.TyCl.badDataConTyCon`) rather
        than the renamer, but now the relevant code from the typechecker
        can simply be deleted.
        One nice side effect of this change is that we are able to give a
        more accurate error message for GADT constructors that use visible
        dependent quantification (e.g., `MkFoo :: forall a -> a -> Foo a`),
        which improves the stderr in the `T16326_Fail6` test case.
      Fixes #18191. Bumps the Haddock submodule.
  5. 05 Jun, 2020 1 commit
    • Simon Peyton Jones's avatar
      Simple subsumption · 2b792fac
      Simon Peyton Jones authored and Ben Gamari's avatar Ben Gamari committed
      This patch simplifies GHC to use simple subsumption.
        Ticket #17775
      Implements GHC proposal #287
      All the motivation is described there; I will not repeat it here.
      The implementation payload:
       * tcSubType and friends become noticably simpler, because it no
         longer uses eta-expansion when checking subsumption.
       * No deeplyInstantiate or deeplySkolemise
      That in turn means that some tests fail, by design; they can all
      be fixed by eta expansion.  There is a list of such changes below.
      Implementing the patch led me into a variety of sticky corners, so
      the patch includes several othe changes, some quite significant:
      * I made String wired-in, so that
          "foo" :: String   rather than
          "foo" :: [Char]
        This improves error messages, and fixes #15679
      * The pattern match checker relies on knowing about in-scope equality
        constraints, andd adds them to the desugarer's environment using
        addTyCsDs.  But the co_fn in a FunBind was missed, and for some reason
        simple-subsumption ends up with dictionaries there. So I added a
        call to addTyCsDs.  This is really part of #18049.
      * I moved the ic_telescope field out of Implication and into
        ForAllSkol instead.  This is a nice win; just expresses the code
        much better.
      * There was a bug in GHC.Tc.TyCl.Instance.tcDataFamInstHeader.
        We called checkDataKindSig inside tc_kind_sig, /before/
        solveEqualities and zonking.  Obviously wrong, easily fixed.
      * solveLocalEqualitiesX: there was a whole mess in here, around
        failing fast enough.  I discovered a bad latent bug where we
        could successfully kind-check a type signature, and use it,
        but have unsolved constraints that could fill in coercion
        holes in that signature --  aargh.
        It's all explained in Note [Failure in local type signatures]
        in GHC.Tc.Solver. Much better now.
      * I fixed a serious bug in anonymous type holes. IN
          f :: Int -> (forall a. a -> _) -> Int
        that "_" should be a unification variable at the /outer/
        level; it cannot be instantiated to 'a'.  This was plain
        wrong.  New fields mode_lvl and mode_holes in TcTyMode,
        and auxiliary data type GHC.Tc.Gen.HsType.HoleMode.
        This fixes #16292, but makes no progress towards the more
        ambitious #16082
      * I got sucked into an enormous refactoring of the reporting of
        equality errors in GHC.Tc.Errors, especially in
        In particular, the very tricky mkExpectedActualMsg function
        is gone.
        It took me a full day.  But the result is far easier to understand.
        (Still not easy!)  This led to various minor improvements in error
        output, and an enormous number of test-case error wibbles.
        One particular point: for occurs-check errors I now just say
           Can't match 'a' against '[a]'
        rather than using the intimidating language of "occurs check".
      * Pretty-printing AbsBinds
      Tests review
      * Eta expansions
         T11305: one eta expansion
         T12082: one eta expansion (undefined)
         T13585a: one eta expansion
         T3102:  one eta expansion
         T3692:  two eta expansions (tricky)
         T2239:  two eta expansions
         T16473: one eta
         determ004: two eta expansions (undefined)
         annfail06: two eta (undefined)
         T17923: four eta expansions (a strange program indeed!)
         tcrun035: one eta expansion
      * Ambiguity check at higher rank.  Now that we have simple
        subsumption, a type like
           f :: (forall a. Eq a => Int) -> Int
        is no longer ambiguous, because we could write
           g :: (forall a. Eq a => Int) -> Int
           g = f
        and it'd typecheck just fine.  But f's type is a bit
        suspicious, and we might want to consider making the
        ambiguity check do a check on each sub-term.  Meanwhile,
        these tests are accepted, whereas they were previously
        rejected as ambiguous:
      * Some more interesting error message wibbles
         T13381: Fine: one error (Int ~ Exp Int)
                 rather than two (Int ~ Exp Int, Exp Int ~ Int)
         T9834:  Small change in error (improvement)
         T10619: Improved
         T2414:  Small change, due to order of unification, fine
         T2534:  A very simple case in which a change of unification order
                 means we get tow unsolved constraints instead of one
         tc211: bizarre impredicative tests; just accept this for now
      Updates Cabal and haddock submodules.
      Metric Increase:
      Metric Decrease:
      Merge note: This appears to break the
      `UnliftedNewtypesDifficultUnification` test. It has been marked as
      broken in the interest of merging.
      (cherry picked from commit 66b7b195)
  6. 01 Jun, 2020 1 commit
  7. 24 May, 2020 1 commit
  8. 21 May, 2020 1 commit
    • Gert-Jan Bottu's avatar
      Explicit Specificity · a9311cd5
      Gert-Jan Bottu authored and  Marge Bot's avatar Marge Bot committed
      Implementation for Ticket #16393.
      Explicit specificity allows users to manually create inferred type variables,
      by marking them with braces.
      This way, the user determines which variables can be instantiated through
      visible type application.
      The additional syntax is included in the parser, allowing users to write
      braces in type variable binders (type signatures, data constructors etc).
      This information is passed along through the renamer and verified in the
      type checker.
      The AST for type variable binders, data constructors, pattern synonyms,
      partial signatures and Template Haskell has been updated to include the
      specificity of type variables.
      Minor notes:
      - Bumps haddock submodule
      - Disables pattern match checking in GHC.Iface.Type with GHC 8.8
  9. 14 May, 2020 1 commit
    • Ryan Scott's avatar
      Factor out HsPatSigType for pat sigs/RULE term sigs (#16762) · 102cfd67
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      This implements chunks (2) and (3) of
      #16762 (comment 270170). Namely,
      it introduces a dedicated `HsPatSigType` AST type, which represents
      the types that can appear in pattern signatures and term-level `RULE`
      binders. Previously, these were represented with `LHsSigWcType`.
      Although `LHsSigWcType` is isomorphic to `HsPatSigType`, the intended
      semantics of the two types are slightly different, as evidenced by
      the fact that they have different code paths in the renamer and
      See also the new `Note [Pattern signature binders and scoping]` in
  10. 26 Apr, 2020 1 commit
  11. 18 Apr, 2020 1 commit
    • Sylvain Henry's avatar
      Modules (#13009) · 15312bbb
      Sylvain Henry authored
      * SysTools
      * Parser
      * GHC.Builtin
      * GHC.Iface.Recomp
      * Settings
      Update Haddock submodule
      Metric Decrease:
  12. 07 Apr, 2020 2 commits
    • Ryan Scott's avatar
      Make NoExtCon fields strict · 04b6cf94
      Ryan Scott authored
      This changes every unused TTG extension constructor to be strict in
      its field so that the pattern-match coverage checker is smart enough
      any such constructors are unreachable in pattern matches. This lets
      us remove nearly every use of `noExtCon` in the GHC API. The only
      ones we cannot remove are ones underneath uses of `ghcPass`, but that
      is only because GHC 8.8's and 8.10's coverage checkers weren't smart
      enough to perform this kind of reasoning. GHC HEAD's coverage
      checker, on the other hand, _is_ smart enough, so we guard these uses
      of `noExtCon` with CPP for now.
      Bumps the `haddock` submodule.
      Fixes #17992.
    • Sylvain Henry's avatar
      Modules: type-checker (#13009) · 255418da
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      Update Haddock submodule
  13. 29 Mar, 2020 1 commit
  14. 17 Mar, 2020 1 commit
  15. 25 Feb, 2020 1 commit
    • Krzysztof Gogolewski's avatar
      Comments, small refactor · 354e2787
      Krzysztof Gogolewski authored and  Marge Bot's avatar Marge Bot committed
      * Remove outdated Note [HsForAllTy tyvar binders] and [Context quantification].
        Since the wildcard refactor 1e041b73, HsForAllTy no longer has an flag
        controlling explicity. The field `hsq_implicit` is gone too.
        The current situation is covered by Note [HsType binders] which is already
        linked from LHsQTyVars.
      * Small refactor in CoreLint, extracting common code to a function
      * Remove "not so sure about WpFun" in TcEvidence, per Richard's comment
        !852 (comment 223226)
      * Use mkIfThenElse in Foreign/Call, as it does exactly what we need.
  16. 24 Feb, 2020 1 commit
    • Vladislav Zavialov's avatar
      Remove Ord SrcLoc, Ord SrcSpan · 26e8fff3
      Vladislav Zavialov authored and  Marge Bot's avatar Marge Bot committed
      Before this patch, GHC relied on Ord SrcSpan to identify source elements, by
      using SrcSpan as Map keys:
      	blackList :: Map SrcSpan ()      -- compiler/GHC/HsToCore/Coverage.hs
      	instanceMap :: Map SrcSpan Name  -- compiler/GHC/HsToCore/Docs.hs
      Firstly, this design is not valid in presence of UnhelpfulSpan, as it
      distinguishes between  UnhelpfulSpan "X"  and  UnhelpfulSpan "Y", but those
      strings are messages for the user, unfit to serve as identifiers for source
      Secondly, this design made it hard to extend SrcSpan with additional data.
      Recall that the definition of SrcSpan is:
      	data SrcSpan =
      	    RealSrcSpan !RealSrcSpan
      	  | UnhelpfulSpan !FastString
      Say we want to extend the RealSrcSpan constructor with additional information:
      	data SrcSpan =
      	    RealSrcSpan !RealSrcSpan !AdditionalInformation
      	  | UnhelpfulSpan !FastString
      	getAdditionalInformation :: SrcSpan -> AdditionalInformation
      	getAdditionalInformation (RealSrcSpan _ a) = a
      Now, in order for  Map SrcSpan  to keep working correctly, we must *ignore* additional
      information when comparing SrcSpan values:
      	instance Ord SrcSpan where
      	  compare (RealSrcSpan r1 _) (RealSrcSpan r2 _) = compare r1 r2
      However, this would violate an important law:
      	a == b  therefore  f a == f b
      Ignoring  AdditionalInformation  in comparisons would mean that with
      f=getAdditionalInformation, the law above does not hold.
      A more robust design is to avoid  Ord SrcSpan  altogether, which is what this patch implements.
      The mappings are changed to use RealSrcSpan instead:
      	blackList :: Set RealSrcSpan         -- compiler/GHC/HsToCore/Coverage.hs
      	instanceMap :: Map RealSrcSpan Name  -- compiler/GHC/HsToCore/Docs.hs
      All SrcSpan comparisons are now done with explicit comparison strategies:
      These strategies are not subject to the law mentioned above and can easily
      discard both the string stored in  UnhelpfulSpan  and  AdditionalInformation.
      Updates haddock submodule.
  17. 08 Feb, 2020 1 commit
    • Richard Eisenberg's avatar
      Introduce IsPass; refactor wrappers. · 7755ffc2
      Richard Eisenberg authored and  Marge Bot's avatar Marge Bot committed
      There are two main payloads of this patch:
      1. This introduces IsPass, which allows e.g. printing
         code to ask what pass it is running in (Renamed vs
         Typechecked) and thus print extension fields. See
         Note [IsPass] in Hs.Extension
      2. This moves the HsWrap constructor into an extension
         field, where it rightly belongs. This is done for
         HsExpr and HsCmd, but not for HsPat, which is left
         as an exercise for the reader.
      There is also some refactoring around SyntaxExprs, but this
      is really just incidental.
      This patch subsumes !1721 (sorry @chreekat).
      Along the way, there is a bit of refactoring in GHC.Hs.Extension,
      including the removal of NameOrRdrName in favor of NoGhcTc.
      This meant that we had no real need for GHC.Hs.PlaceHolder, so
      I got rid of it.
      Updates haddock submodule.
      Metric Decrease:
  18. 27 Jan, 2020 1 commit
    • Ryan Scott's avatar
      Use splitLHs{ForAll,Sigma}TyInvis throughout the codebase · 1132602f
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      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.
  19. 25 Jan, 2020 1 commit
    • Ryan Scott's avatar
      Do not bring visible foralls into scope in hsScopedTvs · 0940b59a
      Ryan Scott authored
      Previously, `hsScopedTvs` (and its cousin `hsWcScopedTvs`) pretended
      that visible dependent quantification could not possibly happen at
      the term level, and cemented that assumption with an `ASSERT`:
          hsScopedTvs (HsForAllTy { hst_fvf = vis_flag, ... }) =
            ASSERT( vis_flag == ForallInvis )
      It turns out that this assumption is wrong. You can end up tripping
      this `ASSERT` if you stick it to the man and write a type for a term
      that uses visible dependent quantification anyway, like in this
      {-# LANGUAGE ScopedTypeVariables #-}
      x :: forall a -> a -> a
      x = x
      That won't typecheck, but that's not the point. Before the
      typechecker has a chance to reject this, the renamer will try
      to use `hsScopedTvs` to bring `a` into scope over the body of `x`,
      since `a` is quantified by a `forall`. This, in turn, causes the
      `ASSERT` to fail. Bummer.
      Instead of walking on this dangerous ground, this patch makes GHC
      adopt a more hardline stance by pattern-matching directly on
      `ForallInvis` in `hsScopedTvs`:
          hsScopedTvs (HsForAllTy { hst_fvf = ForallInvis, ... }) = ...
      Now `a` will not be brought over the body of `x` at all (which is how
      it should be), there's no chance of the `ASSERT` failing anymore (as
      it's gone), and best of all, the behavior of `hsScopedTvs` does not
      change. Everyone wins!
      Fixes #17687.
  20. 13 Jan, 2020 1 commit
  21. 08 Jan, 2020 1 commit
  22. 06 Jan, 2020 1 commit
  23. 05 Dec, 2019 1 commit
    • Vladislav Zavialov's avatar
      Pretty-printing of the * kind · 3354c68e
      Vladislav Zavialov authored and  Marge Bot's avatar Marge Bot committed
      Before this patch, GHC always printed the * kind unparenthesized.
      This led to two issues:
      1. Sometimes GHC printed invalid or incorrect code.
         For example, GHC would print:  type F @*   x = x
               when it meant to print:  type F @(*) x = x
         In the former case, instead of a kind application we were getting a
         type operator (@*).
      2. Sometimes GHC printed kinds that were correct but hard to read.
         Should  Either * Int  be read as  Either (*) Int
                                    or as  (*) Either Int  ?
         This depends on whether -XStarIsType is enabled, but it would be
         easier if we didn't have to check for the flag when reading the code.
      We can solve both problems by assigning (*) a different precedence. Note
      that Haskell98 kinds are not affected:
        ((* -> *) -> *) -> *  does NOT become  (((*) -> (*)) -> (*)) -> (*)
      The parentheses are added when (*) is used in a function argument
         F * * *   becomes  F (*) (*) (*)
         F A * B   becomes  F A (*) B
         Proxy *   becomes  Proxy (*)
         a * -> *  becomes  a (*) -> *
  24. 30 Nov, 2019 1 commit
  25. 25 Nov, 2019 1 commit
  26. 07 Nov, 2019 1 commit
    • Ryan Scott's avatar
      Clean up TH's treatment of unary tuples (or, #16881 part two) · 708c60aa
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      !1906 left some loose ends in regards to Template Haskell's treatment
      of unary tuples. This patch ends to tie up those loose ends:
      * In addition to having `TupleT 1` produce unary tuples, `TupE [exp]`
        and `TupP [pat]` also now produce unary tuples.
      * I have added various special cases in GHC's pretty-printers to
        ensure that explicit 1-tuples are printed using the `Unit` type.
        See `testsuite/tests/th/T17380`.
      * The GHC 8.10.1 release notes entry has been tidied up a little.
      Fixes #16881. Fixes #17371. Fixes #17380.
  27. 28 Oct, 2019 1 commit
    • Sebastian Graf's avatar
      Use FlexibleInstances for `Outputable (* p)` instead of match-all instances... · e951f219
      Sebastian Graf authored and  Marge Bot's avatar Marge Bot committed
      Use FlexibleInstances for `Outputable (* p)` instead of match-all instances with equality constraints
      In #17304, Richard and Simon dicovered that using `-XFlexibleInstances`
      for `Outputable` instances of AST data types means users can provide orphan
      `Outputable` instances for passes other than `GhcPass`.
      Type inference doesn't currently to suffer, and Richard gave an example
      in #17304 that shows how rare a case would be where the slightly worse
      type inference would matter.
      So I went ahead with the refactoring, attempting to fix #17304.
  28. 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
      * '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.
  29. 20 Sep, 2019 1 commit
  30. 15 Aug, 2019 1 commit
    • James Foster's avatar
      Remove unused imports of the form 'import foo ()' (Fixes #17065) · ca71d551
      James Foster authored and  Marge Bot's avatar Marge Bot committed
      These kinds of imports are necessary in some cases such as
      importing instances of typeclasses or intentionally creating
      dependencies in the build system, but '-Wunused-imports' can't
      detect when they are no longer needed. This commit removes the
      unused ones currently in the code base (not including test files
      or submodules), with the hope that doing so may increase
      parallelism in the build system by removing unnecessary
  31. 25 Jul, 2019 1 commit
  32. 09 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Use an empty data type in TTG extension constructors (#15247) · 6a03d77b
      Ryan Scott authored and Ben Gamari's avatar Ben Gamari committed
      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.
  33. 14 Jun, 2019 1 commit
    • Andrew Martin's avatar
      Implement the -XUnliftedNewtypes extension. · effdd948
      Andrew Martin authored and  Marge Bot's avatar Marge Bot committed
      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>
  34. 20 Apr, 2019 1 commit
    • Alec Theriault's avatar
      Haddock: support strict GADT args with docs · 99dd5d6b
      Alec Theriault authored and  Marge Bot's avatar Marge Bot committed
      Rather than massaging the output of the parser to re-arrange docs and
      bangs, it is simpler to patch the two places in which the strictness
      info is needed (to accept that the `HsBangTy` may be inside an
      Fixes #16585.
  35. 15 Mar, 2019 1 commit
  36. 09 Mar, 2019 1 commit
    • Simon Peyton Jones's avatar
      Stop inferring over-polymorphic kinds · 1f5cc9dc
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      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.
  37. 05 Mar, 2019 1 commit
    • Simon Peyton Jones's avatar
      Be more careful when naming TyCon binders · 80dfcee6
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      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.
  38. 01 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Visible dependent quantification · c26d299d
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      This implements GHC proposal 35
      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.
  39. 14 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Make a smart mkAppTyM · 68278382
      Simon Peyton Jones authored
      This patch finally delivers on Trac #15952.  Specifically
      * Completely remove Note [The tcType invariant], along with
        its complicated consequences (IT1-IT6).
      * Replace Note [The well-kinded type invariant] with:
            Note [The Purely Kinded Type Invariant (PKTI)]
      * Instead, establish the (PKTI) in TcHsType.tcInferApps,
        by using a new function mkAppTyM when building a type
        application.  See Note [mkAppTyM].
      * As a result we can remove the delicate mkNakedXX functions
        entirely.  Specifically, mkNakedCastTy retained lots of
        extremly delicate Refl coercions which just cluttered
        everything up, and(worse) were very vulnerable to being
        silently eliminated by (say) substTy. This led to a
        succession of bug reports.
      The result is noticeably simpler to explain, simpler
      to code, and Richard and I are much more confident that
      it is correct.
      It does not actually fix any bugs, but it brings us closer.
      E.g. I hoped it'd fix #15918 and #15799, but it doesn't quite
      do so.  However, it makes it much easier to fix.
      I also did a raft of other minor refactorings:
      * Use tcTypeKind consistently in the type checker
      * Rename tcInstTyBinders to tcInvisibleTyBinders,
        and refactor it a bit
      * Refactor tcEqType, pickyEqType, tcEqTypeVis
        Simpler, probably more efficient.
      * Make zonkTcType zonk TcTyCons, at least if they have
        any free unification variables -- see zonk_tc_tycon
        in TcMType.zonkTcTypeMapper.
        Not zonking these TcTyCons was actually a bug before.
      * Simplify try_to_reduce_no_cache in TcFlatten (a lot)
      * Combine checkExpectedKind and checkExpectedKindX.
        And then combine the invisible-binder instantation code
        Much simpler now.
      * Fix a little bug in TcMType.skolemiseQuantifiedTyVar.
        I'm not sure how I came across this originally.
      * Fix a little bug in TyCoRep.isUnliftedRuntimeRep
        (the ASSERT was over-zealous).  Again I'm not certain
        how I encountered this.
      * Add a missing solveLocalEqualities in
        I came across this when trying to get level numbers