1. 26 Oct, 2021 1 commit
    • sheaf's avatar
      Don't default type variables in type families · 9cc6c193
      sheaf authored and  Marge Bot's avatar Marge Bot committed
        This patch removes the following defaulting of type variables
        in type and data families:
      
          - type variables of kind RuntimeRep defaulting to LiftedRep
          - type variables of kind Levity defaulting to Lifted
          - type variables of kind Multiplicity defaulting to Many
      
        It does this by passing "defaulting options" to the `defaultTyVars`
        function; when calling from `tcTyFamInstEqnGuts` or
        `tcDataFamInstHeader` we pass options that avoid defaulting.
      
        This avoids wildcards being defaulted, which caused type families
        to unexpectedly fail to reduce.
      
        Note that kind defaulting, applicable only with -XNoPolyKinds,
        is not changed by this patch.
      
        Fixes #17536
      
      -------------------------
      Metric Increase:
          T12227
      -------------------------
      9cc6c193
  2. 02 Oct, 2021 1 commit
  3. 29 Sep, 2021 2 commits
  4. 28 Jun, 2021 1 commit
    • Alfredo Di Napoli's avatar
      Try to simplify zoo of functions in `Tc.Utils.Monad` · 755cb2b0
      Alfredo Di Napoli authored and  Marge Bot's avatar Marge Bot committed
      This commit tries to untangle the zoo of diagnostic-related functions
      in `Tc.Utils.Monad` so that we can have the interfaces mentions only
      `TcRnMessage`s while we push the creation of these messages upstream.
      
      It also ports TcRnMessage diagnostics to use the new API, in particular
      this commit switch to use TcRnMessage in the external interfaces
      of the diagnostic functions, and port the old SDoc to be wrapped
      into TcRnUnknownMessage.
      755cb2b0
  5. 17 Jun, 2021 1 commit
  6. 21 May, 2021 1 commit
  7. 13 May, 2021 3 commits
    • Sylvain Henry's avatar
      Remove useless {-# LANGUAGE CPP #-} pragmas · 67a5a91e
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      67a5a91e
    • Sylvain Henry's avatar
      Fully remove HsVersions.h · 0ef11907
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      Replace uses of WARN macro with calls to:
      
        warnPprTrace :: Bool -> SDoc -> a -> a
      
      Remove the now unused HsVersions.h
      
      Bump haddock submodule
      0ef11907
    • Sylvain Henry's avatar
      Replace CPP assertions with Haskell functions · bfabf94f
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      There is no reason to use CPP. __LINE__ and __FILE__ macros are now
      better replaced with GHC's CallStack. As a bonus, assert error messages
      now contain more information (function name, column).
      
      Here is the mapping table (HasCallStack omitted):
      
        * ASSERT:   assert     :: Bool -> a -> a
        * MASSERT:  massert    :: Bool -> m ()
        * ASSERTM:  assertM    :: m Bool -> m ()
        * ASSERT2:  assertPpr  :: Bool -> SDoc -> a -> a
        * MASSERT2: massertPpr :: Bool -> SDoc -> m ()
        * ASSERTM2: assertPprM :: m Bool -> SDoc -> m ()
      bfabf94f
  8. 29 Apr, 2021 1 commit
    • Sylvain Henry's avatar
      Replace (ptext .. sLit) with `text` · 1d03d8be
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      1. `text` is as efficient as `ptext . sLit` thanks to the rewrite rules
      
      2. `text` is visually nicer than `ptext . sLit`
      
      3. `ptext . sLit` encourages using one `ptext` for several `sLit` as in:
      
          ptext $ case xy of
            ... -> sLit ...
            ... -> sLit ...
      
        which may allocate SDoc's TextBeside constructors at runtime instead
        of sharing them into CAFs.
      1d03d8be
  9. 12 Apr, 2021 1 commit
    • Simon Peyton Jones's avatar
      More accurate SrcSpan when reporting redundant constraints · 792d9289
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      We want an accurate SrcSpan for redundant constraints:
      
              • Redundant constraint: Eq a
              • In the type signature for:
                     f :: forall a. Eq a => a -> ()
            |
          5 | f :: Eq a => a -> ()
            |      ^^^^
      
      This patch adds some plumbing to achieve this
      
      * New data type GHC.Tc.Types.Origin.ReportRedundantConstraints (RRC)
      
      * This RRC value is kept inside
        - FunSigCtxt
        - ExprSigCtxt
      
      * Then, when reporting the error in GHC.Tc.Errors, use this SrcSpan
        to control the error message: GHC.Tc.Errors.warnRedundantConstraints
      
      Quite a lot of files are touched in a boring way.
      792d9289
  10. 31 Mar, 2021 1 commit
    • Simon Peyton Jones's avatar
      The result kind of a signature can't mention quantified vars · dbadd672
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      This patch fixes a small but egregious bug, which allowed
      a type signature like
          f :: forall a. blah
      not to fail if (blah :: a).  Acutally this only showed
      up as a ASSERT error (#19495).
      
      The fix is very short, but took quite a bit of head scratching
      
      Hence the long Note [Escaping kind in type signatures]
      
      While I was in town, I also added a short-cut for the
      common case of having no quantifiers to tcImplicitTKBndrsX.
      
      Metric Decrease:
          T9198
      
      Metric Increase:
          T9198
      dbadd672
  11. 20 Mar, 2021 1 commit
  12. 14 Mar, 2021 1 commit
    • Sebastian Graf's avatar
      Implement the UnliftedDatatypes extension · b73c9c5f
      Sebastian Graf authored and  Marge Bot's avatar Marge Bot committed
      GHC Proposal: 0265-unlifted-datatypes.rst
      Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/265
      Issues: ghc/ghc#19523
      Implementation Details: Note [Implementation of UnliftedDatatypes]
      
      This patch introduces the `UnliftedDatatypes` extension. When this extension is
      enabled, GHC relaxes the restrictions around what result kinds are allowed in
      data declarations. This allows data types for which an unlifted or
      levity-polymorphic result kind is inferred.
      
      The most significant changes are in `GHC.Tc.TyCl`, where
      `Note [Implementation of UnliftedDatatypes]` describes the details of the
      implementation.
      
      Fixes #19523.
      b73c9c5f
  13. 01 Mar, 2021 1 commit
  14. 06 Feb, 2021 2 commits
    • Brian Wignall's avatar
      Fix typos · 3da472f0
      Brian Wignall authored and  Marge Bot's avatar Marge Bot committed
      3da472f0
    • Daniel Rogozin's avatar
      The Char kind (#11342) · 7f3524ef
      Daniel Rogozin authored and  Marge Bot's avatar Marge Bot committed
      
      Co-authored-by: Rinat Striungis's avatarRinat Stryungis <rinat.stryungis@serokell.io>
      
      Implement GHC Proposal #387
      
      * Parse char literals 'x' at the type level
      * New built-in type families CmpChar, ConsSymbol, UnconsSymbol
      * New KnownChar class (cf. KnownSymbol and KnownNat)
      * New SomeChar type (cf. SomeSymbol and SomeNat)
      * CharTyLit support in template-haskell
      
      Updated submodules: binary, haddock.
      
      Metric Decrease:
          T5205
          haddock.base
      
      Metric Increase:
          Naperian
          T13035
      7f3524ef
  15. 30 Jan, 2021 1 commit
  16. 10 Jan, 2021 1 commit
  17. 24 Dec, 2020 1 commit
    • Simon Peyton Jones's avatar
      Clone the binders of a SAKS where necessary · e7d8e4ee
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      Given a kind signature
      
         type T :: forall k. k -> forall k. k -> blah
         data T a b = ...
      
      where those k's have the same unique (which is possible;
      see #19093) we were giving the tyConBinders in tycon T the same
      unique, which caused chaos.
      
      Fix is simple: ensure uniqueness when decomposing the kind signature.
      See GHC.Tc.Gen.HsType.zipBinders
      e7d8e4ee
  18. 21 Dec, 2020 1 commit
    • Simon Peyton Jones's avatar
      Kill floatEqualities completely · 995a8f9d
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      This patch delivers on #17656, by entirel killing off the complex
      floatEqualities mechanism.  Previously, floatEqualities would float an
      equality out of an implication, so that it could be solved at an outer
      level. But now we simply do unification in-place, without floating the
      constraint, relying on level numbers to determine untouchability.
      
      There are a number of important new Notes:
      
      * GHC.Tc.Utils.Unify Note [Unification preconditions]
        describes the preconditions for unification, including both
        skolem-escape and touchability.
      
      * GHC.Tc.Solver.Interact Note [Solve by unification]
        describes what we do when we do unify
      
      * GHC.Tc.Solver.Monad Note [The Unification Level Flag]
        describes how we control solver iteration under this new scheme
      
      * GHC.Tc.Solver.Monad Note [Tracking Given equalities]
        describes how we track when we have Given equalities
      
      * GHC.Tc.Types.Constraint Note [HasGivenEqs]
        is a new explanation of the ic_given_eqs field of an implication
      
      A big raft of subtle Notes in Solver, concerning floatEqualities,
      disappears.
      
      Main code changes:
      
      * GHC.Tc.Solver.floatEqualities disappears entirely
      
      * GHC.Tc.Solver.Monad: new fields in InertCans, inert_given_eq_lvl
        and inert_given_eq, updated by updateGivenEqs
        See Note [Tracking Given equalities].
      
      * In exchange for updateGivenEqa, GHC.Tc.Solver.Monad.getHasGivenEqs
        is much simpler and more efficient
      
      * I found I could kill of metaTyVarUpdateOK entirely
      
      One test case T14683 showed a 5.1% decrease in compile-time
      allocation; and T5631 was down 2.2%. Other changes were small.
      
      Metric Decrease:
          T14683
          T5631
      995a8f9d
  19. 18 Dec, 2020 1 commit
    • Ryan Scott's avatar
      Use HsOuterExplicit in instance sigs in deriving-generated code · 7a93435b
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      Issue #18914 revealed that `GeneralizedNewtypeDeriving` would generate code
      that mentions unbound type variables, which is dangerously fragile. The
      problem (and fix) is described in the new `Wrinkle: Use HsOuterExplicit`
      in `Note [GND and QuantifiedConstraints]`. The gist of it: make sure to
      put the top-level `forall`s in `deriving`-generated instance signatures in an
      `HsOuterExplicit` to ensure that they scope over the bodies of methods
      correctly. A side effect of this process is that it will expand any type
      synonyms in the instance signature, which will surface any `forall`s that
      are hidden underneath type synonyms (such as in the test case for #18914).
      
      While I was in town, I also performed some maintenance on `NewHsTypeX`, which
      powers `GeneralizedNewtypeDeriving`:
      
      * I renamed `NewHsTypeX` to `HsCoreTy`, which more accurately describes its
        intended purpose (#15706). I also made `HsCoreTy` a type synonym instead of
        a newtype, as making it a distinct data type wasn't buying us much.
      * To make sure that mistakes similar to #18914 do not occur later, I added an
        additional validity check when renaming `HsCoreTy`s that complains if an
        `HsCoreTy`s contains an out-of-scope type variable. See the new
        `Note [Renaming HsCoreTys]` in `GHC.Rename.HsType` for the details.
      
      Fixes #15706. Fixes #18914. Bumps the `haddock` submodule.
      7a93435b
  20. 14 Dec, 2020 1 commit
  21. 12 Dec, 2020 1 commit
  22. 08 Dec, 2020 1 commit
    • Simon Peyton Jones's avatar
      Fix kind inference for data types. Again. · 62ed6957
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      This patch fixes several aspects of kind inference for data type
      declarations, especially data /instance/ declarations
      
      Specifically
      
      1. In kcConDecls/kcConDecl make it clear that the tc_res_kind argument
         is only used in the H98 case; and in that case there is no result
         kind signature; and hence no need for the disgusting splitPiTys in
         kcConDecls (now thankfully gone).
      
         The GADT case is a bit different to before, and much nicer.
         This is what fixes #18891.
      
         See Note [kcConDecls: kind-checking data type decls]
      
      2. Do not look at the constructor decls of a data/newtype instance
         in tcDataFamInstanceHeader. See GHC.Tc.TyCl.Instance
         Note [Kind inference for data family instances].  This was a
         new realisation that arose when doing (1)
      
         This causes a few knock-on effects in the tests suite, because
         we require more information than before in the instance /header/.
      
         New user-manual material about this in "Kind inference in data type
         declarations" and "Kind inference for data/newtype instance
         declarations".
      
      3. Minor improvement in kcTyClDecl, combining GADT and H98 cases
      
      4. Fix #14111 and #8707 by allowing the header of a data instance
         to affect kind inferece for the the data constructor signatures;
         as described at length in Note [GADT return types] in GHC.Tc.TyCl
      
         This led to a modest refactoring of the arguments (and argument
         order) of tcConDecl/tcConDecls.
      
      5. Fix #19000 by inverting the sense of the test in new_locs
         in GHC.Tc.Solver.Canonical.canDecomposableTyConAppOK.
      62ed6957
  23. 02 Dec, 2020 2 commits
    • Richard Eisenberg's avatar
      Rename the flattener to become the rewriter. · d66660ba
      Richard Eisenberg authored and  Marge Bot's avatar Marge Bot committed
      Now that flattening doesn't produce flattening variables,
      it's not really flattening anything: it's rewriting. This
      change also means that the rewriter can no longer be confused
      the core flattener (in GHC.Core.Unify), which is sometimes used
      during type-checking.
      d66660ba
    • Richard Eisenberg's avatar
      Remove flattening variables · 8bb52d91
      Richard Eisenberg authored and  Marge Bot's avatar Marge Bot committed
      This patch redesigns the flattener to simplify type family applications
      directly instead of using flattening meta-variables and skolems. The key new
      innovation is the CanEqLHS type and the new CEqCan constraint (Ct). A CanEqLHS
      is either a type variable or exactly-saturated type family application; either
      can now be rewritten using a CEqCan constraint in the inert set.
      
      Because the flattener no longer reduces all type family applications to
      variables, there was some performance degradation if a lengthy type family
      application is now flattened over and over (not making progress). To
      compensate, this patch contains some extra optimizations in the flattener,
      leading to a number of performance improvements.
      
      Close #18875.
      Close #18910.
      
      There are many extra parts of the compiler that had to be affected in writing
      this patch:
      
      * The family-application cache (formerly the flat-cache) sometimes stores
        coercions built from Given inerts. When these inerts get kicked out, we must
        kick out from the cache as well. (This was, I believe, true previously, but
        somehow never caused trouble.) Kicking out from the cache requires adding a
        filterTM function to TrieMap.
      
      * This patch obviates the need to distinguish "blocking" coercion holes from
        non-blocking ones (which, previously, arose from CFunEqCans). There is thus
        some simplification around coercion holes.
      
      * Extra commentary throughout parts of the code I read through, to preserve
        the knowledge I gained while working.
      
      * A change in the pure unifier around unifying skolems with other types.
        Unifying a skolem now leads to SurelyApart, not MaybeApart, as documented
        in Note [Binding when looking up instances] in GHC.Core.InstEnv.
      
      * Some more use of MCoercion where appropriate.
      
      * Previously, class-instance lookup automatically noticed that e.g. C Int was
        a "unifier" to a target [W] C (F Bool), because the F Bool was flattened to
        a variable. Now, a little more care must be taken around checking for
        unifying instances.
      
      * Previously, tcSplitTyConApp_maybe would split (Eq a => a). This is silly,
        because (=>) is not a tycon in Haskell. Fixed now, but there are some
        knock-on changes in e.g. TrieMap code and in the canonicaliser.
      
      * New function anyFreeVarsOf{Type,Co} to check whether a free variable
        satisfies a certain predicate.
      
      * Type synonyms now remember whether or not they are "forgetful"; a forgetful
        synonym drops at least one argument. This is useful when flattening; see
        flattenView.
      
      * The pattern-match completeness checker invokes the solver. This invocation
        might need to look through newtypes when checking representational equality.
        Thus, the desugarer needs to keep track of the in-scope variables to know
        what newtype constructors are in scope. I bet this bug was around before but
        never noticed.
      
      * Extra-constraints wildcards are no longer simplified before printing.
        See Note [Do not simplify ConstraintHoles] in GHC.Tc.Solver.
      
      * Whether or not there are Given equalities has become slightly subtler.
        See the new HasGivenEqs datatype.
      
      * Note [Type variable cycles in Givens] in GHC.Tc.Solver.Canonical
        explains a significant new wrinkle in the new approach.
      
      * See Note [What might match later?] in GHC.Tc.Solver.Interact, which
        explains the fix to #18910.
      
      * The inert_count field of InertCans wasn't actually used, so I removed
        it.
      
      Though I (Richard) did the implementation, Simon PJ was very involved
      in design and review.
      
      This updates the Haddock submodule to avoid #18932 by adding
      a type signature.
      
      -------------------------
      Metric Decrease:
          T12227
          T5030
          T9872a
          T9872b
          T9872c
      Metric Increase:
          T9872d
      -------------------------
      8bb52d91
  24. 15 Nov, 2020 2 commits
    • Ryan Scott's avatar
      Use tcSplitForAllInvisTyVars (not tcSplitForAllTyVars) in more places · 645444af
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      The use of `tcSplitForAllTyVars` in `tcDataFamInstHeader` was the immediate
      cause of #18939, and replacing it with a new `tcSplitForAllInvisTyVars`
      function (which behaves like `tcSplitForAllTyVars` but only splits invisible
      type variables) fixes the issue. However, this led me to realize that _most_
      uses of `tcSplitForAllTyVars` in GHC really ought to be
      `tcSplitForAllInvisTyVars` instead. While I was in town, I opted to replace
      most uses of `tcSplitForAllTys` with `tcSplitForAllTysInvis` to reduce the
      likelihood of such bugs in the future.
      
      I say "most uses" above since there is one notable place where we _do_ want
      to use `tcSplitForAllTyVars`: in `GHC.Tc.Validity.forAllTyErr`, which produces
      the "`Illegal polymorphic type`" error message if you try to use a higher-rank
      `forall` without having `RankNTypes` enabled. Here, we really do want to split
      all `forall`s, not just invisible ones, or we run the risk of giving an
      inaccurate error message in the newly added `T18939_Fail` test case.
      
      I debated at some length whether I wanted to name the new function
      `tcSplitForAllInvisTyVars` or `tcSplitForAllTyVarsInvisible`, but in the end,
      I decided that I liked the former better. For consistency's sake, I opted to
      rename the existing `splitPiTysInvisible` and `splitPiTysInvisibleN` functions
      to `splitInvisPiTys` and `splitPiTysInvisN`, respectively, so that they use the
      same naming convention. As a consequence, this ended up requiring a `haddock`
      submodule bump.
      
      Fixes #18939.
      645444af
    • Ryan Scott's avatar
      Name (tc)SplitForAll- functions more consistently · d61adb3d
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      There is a zoo of `splitForAll-` functions in `GHC.Core.Type` (as well as
      `tcSplitForAll-` functions in `GHC.Tc.Utils.TcType`) that all do very similar
      things, but vary in the particular form of type variable that they return. To
      make things worse, the names of these functions are often quite misleading.
      Some particularly egregious examples:
      
      * `splitForAllTys` returns `TyCoVar`s, but `splitSomeForAllTys` returns
        `VarBndr`s.
      * `splitSomeForAllTys` returns `VarBndr`s, but `tcSplitSomeForAllTys` returns
        `TyVar`s.
      * `splitForAllTys` returns `TyCoVar`s, but `splitForAllTysInvis` returns
        `InvisTVBinder`s. (This in particular arose in the context of #18939, and
        this finally motivated me to bite the bullet and improve the status quo
        vis-à-vis how we name these functions.)
      
      In an attempt to bring some sanity to how these functions are named, I have
      opted to rename most of these functions en masse to use consistent suffixes
      that describe the particular form of type variable that each function returns.
      In concrete terms, this amounts to:
      
      * Functions that return a `TyVar` now use the suffix `-TyVar`.
        This caused the following functions to be renamed:
        * `splitTyVarForAllTys` -> `splitForAllTyVars`
        * `splitForAllTy_ty_maybe` -> `splitForAllTyVar_maybe`
        * `tcSplitForAllTys` -> `tcSplitForAllTyVars`
        * `tcSplitSomeForAllTys` -> `tcSplitSomeForAllTyVars`
      * Functions that return a `CoVar` now use the suffix `-CoVar`.
        This caused the following functions to be renamed:
        * `splitForAllTy_co_maybe` -> `splitForAllCoVar_maybe`
      * Functions that return a `TyCoVar` now use the suffix `-TyCoVar`.
        This caused the following functions to be renamed:
        * `splitForAllTy` -> `splitForAllTyCoVar`
        * `splitForAllTys` -> `splitForAllTyCoVars`
        * `splitForAllTys'` -> `splitForAllTyCoVars'`
        * `splitForAllTy_maybe` -> `splitForAllTyCoVar_maybe`
      * Functions that return a `VarBndr` now use the suffix corresponding to the
        most relevant type synonym. This caused the following functions to be renamed:
        * `splitForAllVarBndrs` -> `splitForAllTyCoVarBinders`
        * `splitForAllTysInvis` -> `splitForAllInvisTVBinders`
        * `splitForAllTysReq` -> `splitForAllReqTVBinders`
        * `splitSomeForAllTys` -> `splitSomeForAllTyCoVarBndrs`
        * `tcSplitForAllVarBndrs` -> `tcSplitForAllTyVarBinders`
        * `tcSplitForAllTysInvis` -> `tcSplitForAllInvisTVBinders`
        * `tcSplitForAllTysReq` -> `tcSplitForAllReqTVBinders`
        * `tcSplitForAllTy_maybe` -> `tcSplitForAllTyVarBinder_maybe`
      
      Note that I left the following functions alone:
      
      * Functions that split apart things besides `ForAllTy`s, such as `splitFunTys`
        or `splitPiTys`. Thankfully, there are far fewer of these functions than
        there are functions that split apart `ForAllTy`s, so there isn't much of a
        pressing need to apply the new naming convention elsewhere.
      * Functions that split apart `ForAllCo`s in `Coercion`s, such as
        `GHC.Core.Coercion.splitForAllCo_maybe`. We could theoretically apply the new
        naming convention here, but then we'd have to figure out how to disambiguate
        `Type`-splitting functions from `Coercion`-splitting functions. Ultimately,
        the `Coercion`-splitting functions aren't used nearly as much as the
        `Type`-splitting functions, so I decided to leave the former alone.
      
      This is purely refactoring and should cause no change in behavior.
      d61adb3d
  25. 06 Nov, 2020 1 commit
    • Ryan Scott's avatar
      Replace HsImplicitBndrs with HsOuterTyVarBndrs · e07e383a
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      This refactors the GHC AST to remove `HsImplicitBndrs` and replace it with
      `HsOuterTyVarBndrs`, a type which records whether the outermost quantification
      in a type is explicit (i.e., with an outermost, invisible `forall`) or
      implicit. As a result of this refactoring, it is now evident in the AST where
      the `forall`-or-nothing rule applies: it's all the places that use
      `HsOuterTyVarBndrs`. See the revamped `Note [forall-or-nothing rule]` in
      `GHC.Hs.Type` (previously in `GHC.Rename.HsType`).
      
      Moreover, the places where `ScopedTypeVariables` brings lexically scoped type
      variables into scope are a subset of the places that adhere to the
      `forall`-or-nothing rule, so this also makes places that interact with
      `ScopedTypeVariables` easier to find. See the revamped
      `Note [Lexically scoped type variables]` in `GHC.Hs.Type` (previously in
      `GHC.Tc.Gen.Sig`).
      
      `HsOuterTyVarBndrs` are used in type signatures (see `HsOuterSigTyVarBndrs`)
      and type family equations (see `HsOuterFamEqnTyVarBndrs`). The main difference
      between the former and the latter is that the former cares about specificity
      but the latter does not.
      
      There are a number of knock-on consequences:
      
      * There is now a dedicated `HsSigType` type, which is the combination of
        `HsOuterSigTyVarBndrs` and `HsType`. `LHsSigType` is now an alias for an
        `XRec` of `HsSigType`.
      * Working out the details led us to a substantial refactoring of
        the handling of explicit (user-written) and implicit type-variable
        bindings in `GHC.Tc.Gen.HsType`.
      
        Instead of a confusing family of higher order functions, we now
        have a local data type, `SkolemInfo`, that controls how these
        binders are kind-checked.
      
        It remains very fiddly, not fully satisfying. But it's better
        than it was.
      
      Fixes #16762
      
      . Bumps the Haddock submodule.
      Co-authored-by: default avatarSimon Peyton Jones <simonpj@microsoft.com>
      Co-authored-by: Richard Eisenberg's avatarRichard Eisenberg <rae@richarde.dev>
      Co-authored-by: Zubin's avatarZubin Duggal <zubin@cmi.ac.in>
      e07e383a
  26. 01 Nov, 2020 1 commit
  27. 29 Oct, 2020 1 commit
    • Ryan Scott's avatar
      Check for large tuples more thoroughly · 2ef2fac4
      Ryan Scott authored
      This fixes #18723 by:
      
      * Moving the existing `GHC.Tc.Gen.HsType.bigConstraintTuple` validity
        check to `GHC.Rename.Utils.checkCTupSize` for consistency with
        `GHC.Rename.Utils.checkTupSize`, and
      * Using `check(C)TupSize` when checking tuple _types_, in addition
        to checking names, expressions, and patterns.
      
      Note that I put as many of these checks as possible in the typechecker so
      that GHC can properly distinguish between boxed and constraint tuples. The
      exception to this rule is checking names, which I perform in the renamer
      (in `GHC.Rename.Env`) so that we can rule out `(,, ... ,,)` and
      `''(,, ... ,,)` alike in one fell swoop.
      
      While I was in town, I also removed the `HsConstraintTuple` and
      `HsBoxedTuple` constructors of `HsTupleSort`, which are functionally
      unused. This requires a `haddock` submodule bump.
      2ef2fac4
  28. 20 Oct, 2020 1 commit
    • Alan Zimmerman's avatar
      API Annotations: Keep track of unicode for linear arrow notation · ea736839
      Alan Zimmerman authored
      The linear arrow can be parsed as `%1 ->` or a direct single token unicode
      equivalent.
      
      Make sure that this distinction is captured in the parsed AST by using
      IsUnicodeSyntax where it appears, and introduce a new API Annotation,
      AnnMult to represent its location when unicode is not used.
      
      Updated haddock submodule
      ea736839
  29. 16 Oct, 2020 1 commit
  30. 13 Oct, 2020 1 commit
    • Rinat Striungis's avatar
      Unification of Nat and Naturals · 8f4f5794
      Rinat Striungis authored
      This commit removes the separate kind 'Nat' and enables promotion
      of type 'Natural' for using as type literal.
      It partially solves #10776
      
      Now the following code will be successfully typechecked:
          data C = MkC Natural
          type CC = MkC 1
      
      Before this change we had to create the separate type for promotion
          data C = MkC Natural
          data CP = MkCP Nat
          type CC = MkCP 1
      
      But CP is uninhabited in terms.
      
      For backward compatibility type synonym `Nat` has been made:
          type Nat = Natural
      
      The user's documentation and tests have been updated.
      The haddock submodule also have been updated.
      8f4f5794
  31. 10 Oct, 2020 1 commit
  32. 02 Oct, 2020 1 commit
  33. 24 Sep, 2020 1 commit
    • Simon Peyton Jones's avatar
      Improve kind generalisation, error messages · 9fa26aa1
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      This patch does two things:
      
      * It refactors GHC.Tc.Errors a bit.  In debugging Quick Look I was
        forced to look in detail at error messages, and ended up doing a bit
        of refactoring, esp in mkTyVarEqErr'.  It's still quite a mess, but
        a bit better, I think.
      
      * It makes a significant improvement to the kind checking of type and
        class declarations. Specifically, we now ensure that if kind
        checking fails with an unsolved constraint, all the skolems are in
        scope.  That wasn't the case before, which led to some obscure error
        messages; and occasional failures with "no skolem info" (eg #16245).
      
      Both of these, and the main Quick Look patch itself, affect a /lot/ of
      error messages, as you can see from the number of files changed.  I've
      checked them all; I think they are as good or better than before.
      
      Smaller things
      
      * I documented the various instances of VarBndr better.
        See Note [The VarBndr tyep and its uses] in GHC.Types.Var
      
      * Renamed GHC.Tc.Solver.simpl_top to simplifyTopWanteds
      
      * A bit of refactoring in bindExplicitTKTele, to avoid the
        footwork with Either.  Simpler now.
      
      * Move promoteTyVar from GHC.Tc.Solver to GHC.Tc.Utils.TcMType
      
      Fixes #16245 (comment 211369), memorialised as
        typecheck/polykinds/T16245a
      Also fixes the three bugs in #18640
      9fa26aa1
  34. 21 Sep, 2020 1 commit