1. 28 Nov, 2019 1 commit
  2. 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
  3. 08 Oct, 2019 1 commit
    • Richard Eisenberg's avatar
      Solve constraints from top-level groups sooner · 9612e91c
      Richard Eisenberg authored
      Previously, all constraints from all top-level groups (as
      separated by top-level splices) were lumped together and solved
      at the end. This could leak metavariables to TH, though, and
      that's bad. This patch solves each group's constraints before
      running the next group's splice.
      
      Naturally, we now report fewer errors in some cases.
      
      One nice benefit is that this also fixes #11680, but in a much
      simpler way than the original fix for that ticket. Admittedly,
      the error messages degrade just a bit from the fix from #11680
      (previously, we informed users about variables that will be
      brought into scope below a top-level splice, and now we just
      report an out-of-scope error), but the amount of complexity
      required throughout GHC to get that error was just not worth it.
      
      This patch thus reverts much of
      f93c9517.
      
      Fixes #16980
      
      Test cases: th/T16980{,a}
      9612e91c
  4. 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
  5. 20 Sep, 2019 1 commit
  6. 19 Aug, 2019 1 commit
  7. 26 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Banish reportFloatingViaTvs to the shadow realm (#15831, #16181) · 30b6f391
      Ryan Scott authored
      GHC used to reject programs of this form:
      
      ```
      newtype Age = MkAge Int
        deriving Eq via Const Int a
      ```
      
      That's because an earlier implementation of `DerivingVia` would
      generate the following instance:
      
      ```
      instance Eq Age where
        (==) = coerce @(Const Int a -> Const Int a -> Bool)
                      @(Age         -> Age         -> Bool)
                      (==)
      ```
      
      Note that the `a` in `Const Int a` is not bound anywhere, which
      causes all sorts of issues. I figured that no one would ever want to
      write code like this anyway, so I simply banned "floating" `via` type
      variables like `a`, checking for their presence in the aptly named
      `reportFloatingViaTvs` function.
      
      `reportFloatingViaTvs` ended up being implemented in a subtly
      incorrect way, as #15831 demonstrates. Following counsel with the
      sage of gold fire, I decided to abandon `reportFloatingViaTvs`
      entirely and opt for a different approach that would _accept_
      the instance above. This is because GHC now generates this instance
      instead:
      
      ```
      instance forall a. Eq Age where
        (==) = coerce @(Const Int a -> Const Int a -> Bool)
                      @(Age         -> Age         -> Bool)
                      (==)
      ```
      
      Notice that we now explicitly quantify the `a` in
      `instance forall a. Eq Age`, so everything is peachy scoping-wise.
      See `Note [Floating `via` type variables]` in `TcDeriv` for the full
      scoop.
      
      A pleasant benefit of this refactoring is that it made it much easier
      to catch the problem observed in #16181, so this patch fixes that
      issue too.
      
      Fixes #15831. Fixes #16181.
      30b6f391
  8. 25 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Make DefUses = OrdList DefUse · cb495b3c
      Ryan Scott authored
      Before, `type DefUses = [DefUse]`. But lists are a terrible choice of
      data structure here, as we frequently append to the right of a
      `DefUses`, which yields some displeasing asymptotics. Let's instead
      use `OrdList`, which has constant-time appending to the right.
      
      This is one step on the way to #10347.
      cb495b3c
  9. 19 Jul, 2019 1 commit
  10. 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
  11. 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
  12. 22 May, 2019 1 commit
    • Ryan Scott's avatar
      Use HsTyPats in associated type family defaults · 6efe04de
      Ryan Scott authored
      Associated type family default declarations behave strangely in a
      couple of ways:
      
      1. If one tries to bind the type variables with an explicit `forall`,
         the `forall`'d part will simply be ignored. (#16110)
      2. One cannot use visible kind application syntax on the left-hand
         sides of associated default equations, unlike every other form
         of type family equation. (#16356)
      
      Both of these issues have a common solution. Instead of using
      `LHsQTyVars` to represent the left-hand side arguments of an
      associated default equation, we instead use `HsTyPats`, which is what
      other forms of type family equations use. In particular, here are
      some highlights of this patch:
      
      * `FamEqn` is no longer parameterized by a `pats` type variable, as
        the `feqn_pats` field is now always `HsTyPats`.
      * The new design for `FamEqn` in chronicled in
        `Note [Type family instance declarations in HsSyn]`.
      * `TyFamDefltEqn` now becomes the same thing as `TyFamInstEqn`. This
        means that many of `TyFamDefltEqn`'s code paths can now reuse the
        code paths for `TyFamInstEqn`, resulting in substantial
        simplifications to various parts of the code dealing with
        associated type family defaults.
      
      Fixes #16110 and #16356.
      6efe04de
  13. 14 May, 2019 1 commit
    • Vladislav Zavialov's avatar
      Guard CUSKs behind a language pragma · a5fdd185
      Vladislav Zavialov authored
      GHC Proposal #36 describes a transition plan away from CUSKs and to
      top-level kind signatures:
      
      1. Introduce a new extension, -XCUSKs, on by default, that detects CUSKs
         as they currently exist.
      2. We turn off the -XCUSKs extension in a few releases and remove it
         sometime thereafter.
      
      This patch implements phase 1 of this plan, introducing a new language
      extension to control whether CUSKs are enabled. When top-level kind
      signatures are implemented, we can transition to phase 2.
      a5fdd185
  14. 22 Mar, 2019 1 commit
  15. 15 Mar, 2019 1 commit
  16. 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
  17. 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
  18. 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
  19. 15 Jan, 2019 2 commits
  20. 06 Jan, 2019 1 commit
  21. 03 Jan, 2019 1 commit
    • My Nguyen's avatar
      Visible kind application · 17bd1635
      My Nguyen authored
      Summary:
      This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362.
      It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be
      written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind
      application, just like in term-level.
      
      There are a few remaining issues with this patch, as documented in
      ticket #16082.
      
      Includes a submodule update for Haddock.
      
      Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a
      
      Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack
      
      Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter
      
      GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816`
      
      Differential Revision: https://phabricator.haskell.org/D5229
      17bd1635
  22. 21 Dec, 2018 2 commits
    • Simon Peyton Jones's avatar
      Comments only · 28188e06
      Simon Peyton Jones authored
      28188e06
    • Ryan Scott's avatar
      Fix #16002 by moving a validity check to the renamer · 28f41f1a
      Ryan Scott authored
      Summary:
      The validity check which rejected things like:
      
      ```lang=haskell
      type family B x where
        A x = x
      ```
      
      Used to live in the typechecker. But it turns out that this validity
      check was //only// being run on closed type families without CUSKs!
      This meant that GHC would silently accept something like this:
      
      ```lang=haskell
      type family B (x :: *) :: * where
        A x = x
      ```
      
      This patch fixes the issue by moving this validity check to the
      renamer, where we can be sure that the check will //always// be run.
      
      Test Plan: make test TEST=T16002
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: goldfire, rwbarton, carter
      
      GHC Trac Issues: #16002
      
      Differential Revision: https://phabricator.haskell.org/D5420
      28f41f1a
  23. 29 Nov, 2018 1 commit
    • mayac's avatar
      Fix #15828, from `More explicit foralls` · fe57a5ba
      mayac authored
      Summary:
      Fix a bug in commit 12eeb9 which permits the following:
      
      ```
      class C a where
        type T a b
      instance C (Maybe a) where
        type forall a b. T (Maybe a) b = b
      ```
      
      where instead, the user should write:
      
      ```
      instance C (Maybe a) where
        type forall b. T (Maybe a) b = b
      ```
      
      Update the users guide to discuss scoping of type variables in
      explicit foralls in type family instances.
      
      Test Plan: validate
      
      Reviewers: bgamari, goldfire, monoidal
      
      Reviewed By: goldfire
      
      Subscribers: monoidal, rwbarton, carter
      
      GHC Trac Issues: #15828
      
      Differential Revision: https://phabricator.haskell.org/D5283
      fe57a5ba
  24. 24 Nov, 2018 1 commit
  25. 22 Nov, 2018 1 commit
    • David Eichmann's avatar
      Fix unused-import warnings · 6353efc7
      David Eichmann authored
      This patch fixes a fairly long-standing bug (dating back to 2015) in
      RdrName.bestImport, namely
      
         commit 9376249b
         Author: Simon Peyton Jones <simonpj@microsoft.com>
         Date:   Wed Oct 28 17:16:55 2015 +0000
      
         Fix unused-import stuff in a better way
      
      In that patch got the sense of the comparison back to front, and
      thereby failed to implement the unused-import rules described in
        Note [Choosing the best import declaration] in RdrName
      
      This led to Trac #13064 and #15393
      
      Fixing this bug revealed a bunch of unused imports in libraries;
      the ones in the GHC repo are part of this commit.
      
      The two important changes are
      
      * Fix the bug in bestImport
      
      * Modified the rules by adding (a) in
           Note [Choosing the best import declaration] in RdrName
        Reason: the previosu rules made Trac #5211 go bad again.  And
        the new rule (a) makes sense to me.
      
      In unravalling this I also ended up doing a few other things
      
      * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the
        things that are used, rather than [AvailInfo]. This is simpler
        and more direct.
      
      * Rename greParentName to greParent_maybe, to follow GHC
        naming conventions
      
      * Delete dead code RdrName.greUsedRdrName
      
      Bumps a few submodules.
      
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5312
      6353efc7
  26. 27 Oct, 2018 1 commit
    • mayac's avatar
      More explicit foralls (GHC Proposal 0007) · 512eeb9b
      mayac authored
      Allow the user to explicitly bind type/kind variables in type and data
      family instances (including associated instances), closed type family
      equations, and RULES pragmas. Follows the specification of GHC
      Proposal 0007, also fixes #2600. Advised by Richard Eisenberg.
      
      This modifies the Template Haskell AST -- old code may break!
      
      Other Changes:
      - convert HsRule to a record
      - make rnHsSigWcType more general
      - add repMaybe to DsMeta
      
      Includes submodule update for Haddock.
      
      Test Plan: validate
      
      Reviewers: goldfire, bgamari, alanz
      
      Subscribers: simonpj, RyanGlScott, goldfire, rwbarton,
                   thomie, mpickering, carter
      
      GHC Trac Issues: #2600, #14268
      
      Differential Revision: https://phabricator.haskell.org/D4894
      512eeb9b
  27. 26 Oct, 2018 1 commit
    • Simon Peyton Jones's avatar
      De-monadise the 'extract' functions in RnTypes · e6bf96c9
      Simon Peyton Jones authored
      As Trac #15765 says, Once upon a time, the extract functions
      at the bottom of RnTypes were pure. Then, along came -XTypeInType,
      which needed to do a check in these functions for users mixing
      type variables with kind variables.
      
      Now, however, with -XTypeInType gone again, we no longer
      do this check. Thus, there is no reason to keep these
      functions monadic.
      e6bf96c9
  28. 23 Sep, 2018 1 commit
    • Simon Peyton Jones's avatar
      Buglet in reporting out of scope errors in rules · cad5d0b6
      Simon Peyton Jones authored
      Most out of scope errors get reported by the type checker these
      days, but not all.  Example, the function on the LHS of a RULE.
      
      Trace #15659 pointed out that this less-heavily-used code path
      produce a "wacky" error message.  Indeed so.  Easily fixed.
      cad5d0b6
  29. 21 Aug, 2018 2 commits
    • Ben Gamari's avatar
      Fix redundant imports of Class · 966aa781
      Ben Gamari authored
      966aa781
    • Simon Peyton Jones's avatar
      Add a solveEqualities to tcClassDecl1 · 43b08cfb
      Simon Peyton Jones authored
      Trac #15505 showed that, when we have a type error, we
      could have an unfilled-in coercion hole.  We don't want an
      assertion error in that case.
      
      The underlying cause is that tcClassDecl1 should call
      solveEqualities to fully solve all top-level equalities
      (or fail in the attempt).
      
      I also refactored the ClassDecl case for tcTyClDecl1 into
      a new function tcClassDecl1.  That makes it symmetrical
      with the others.
      43b08cfb
  30. 17 Aug, 2018 1 commit
  31. 02 Aug, 2018 1 commit
    • Richard Eisenberg's avatar
      Remove decideKindGeneralisationPlan · c955a514
      Richard Eisenberg authored
      TypeInType came with a new function: decideKindGeneralisationPlan.
      This type-level counterpart to the term-level decideGeneralisationPlan
      chose whether or not a kind should be generalized. The thinking was
      that if `let` should not be generalized, then kinds shouldn't either
      (under the same circumstances around -XMonoLocalBinds).
      
      However, this is too conservative -- the situation described in the
      motivation for "let should be be generalized" does not occur in types.
      
      This commit thus removes decideKindGeneralisationPlan, always
      generalizing.
      
      One consequence is that tc_hs_sig_type_and_gen no longer calls
      solveEqualities, which reports all unsolved constraints, instead
      relying on the solveLocalEqualities in tcImplicitTKBndrs. An effect
      of this is that reporing kind errors gets delayed more frequently.
      This seems to be a net benefit in error reporting; often, alongside
      a kind error, the type error is now reported (and users might find
      type errors easier to understand).
      
      Some of these errors ended up at the top level, where it was
      discovered that the GlobalRdrEnv containing the definitions in the
      local module was not in the TcGblEnv, and thus errors were reported
      with qualified names unnecessarily. This commit rejiggers some of
      the logic around captureTopConstraints accordingly.
      
      One error message (typecheck/should_fail/T1633)
      is a regression, mentioning the name of a default method. However,
      that problem is already reported as #10087, its solution is far from
      clear, and so I'm not addressing it here.
      
      This commit fixes #15141. As it's an internal refactor, there is
      no concrete test case for it.
      
      Along the way, we no longer need the hsib_closed field of
      HsImplicitBndrs (it was used only in decideKindGeneralisationPlan)
      and so it's been removed, simplifying the datatype structure.
      
      Along the way, I removed code in the validity checker that looks
      at coercions. This isn't related to this patch, really (though
      it was, at one point), but it's an improvement, so I kept it.
      
      This updates the haddock submodule.
      c955a514
  32. 05 Jul, 2018 1 commit
    • Ryan Scott's avatar
      Instantiate GND bindings with an explicit type signature · 132273f3
      Ryan Scott authored
      Summary:
      Before, we were using visible type application to apply
      impredicative types to `coerce` in
      `GeneralizedNewtypeDeriving`-generated bindings. This approach breaks
      down when combined with `QuantifiedConstraints` in certain ways,
      which #14883 and #15290 provide examples of. See
      Note [GND and QuantifiedConstraints] for all the gory details.
      
      To avoid this issue, we instead use an explicit type signature to
      instantiate each GND binding, and use that to bind any type variables
      that might be bound by a class method's type signature. This reduces
      the need to impredicative type applications, and more importantly,
      makes the programs from #14883 and #15290 work again.
      
      Test Plan: make test TEST="T15290b T15290c T15290d T14883"
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14883, #15290
      
      Differential Revision: https://phabricator.haskell.org/D4895
      132273f3
  33. 19 Jun, 2018 1 commit
    • Alan Zimmerman's avatar
      Fix API Annotations for GADT constructors · 676c5754
      Alan Zimmerman authored
      Summary:
      This patch completes the work for #14529 by making sure that all API
      Annotations end up attached to a SrcSpan that appears in the final
      ParsedSource.
      
      Updates Haddock submodule
      
      Test Plan: ./validate
      
      Reviewers: goldfire, bgamari
      
      Subscribers: rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #14529
      
      Differential Revision: https://phabricator.haskell.org/D4867
      676c5754
  34. 18 Jun, 2018 1 commit
  35. 14 Jun, 2018 1 commit
    • Vladislav Zavialov's avatar
      Embrace -XTypeInType, add -XStarIsType · d650729f
      Vladislav Zavialov authored
      Summary:
      Implement the "Embrace Type :: Type" GHC proposal,
      .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst
      
      GHC 8.0 included a major change to GHC's type system: the Type :: Type
      axiom. Though casual users were protected from this by hiding its
      features behind the -XTypeInType extension, all programs written in GHC
      8+ have the axiom behind the scenes. In order to preserve backward
      compatibility, various legacy features were left unchanged. For example,
      with -XDataKinds but not -XTypeInType, GADTs could not be used in types.
      Now these restrictions are lifted and -XTypeInType becomes a redundant
      flag that will be eventually deprecated.
      
      * Incorporate the features currently in -XTypeInType into the
        -XPolyKinds and -XDataKinds extensions.
      * Introduce a new extension -XStarIsType to control how to parse * in
        code and whether to print it in error messages.
      
      Test Plan: Validate
      
      Reviewers: goldfire, hvr, bgamari, alanz, simonpj
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #15195
      
      Differential Revision: https://phabricator.haskell.org/D4748
      d650729f
  36. 05 Jun, 2018 1 commit
    • Ryan Scott's avatar
      Introduce DerivingVia · 8ed8b037
      Ryan Scott authored
      This implements the `DerivingVia` proposal put forth in
      https://github.com/ghc-proposals/ghc-proposals/pull/120.
      
      This introduces the `DerivingVia` deriving strategy. This is a
      generalization of `GeneralizedNewtypeDeriving` that permits the user
      to specify the type to `coerce` from.
      
      The major change in this patch is the introduction of the
      `ViaStrategy` constructor to `DerivStrategy`, which takes a type
      as a field. As a result, `DerivStrategy` is no longer a simple
      enumeration type, but rather something that must be renamed and
      typechecked. The process by which this is done is explained more
      thoroughly in section 3 of this paper
      ( https://www.kosmikus.org/DerivingVia/deriving-via-paper.pdf ),
      although I have inlined the relevant parts into Notes where possible.
      
      There are some knock-on changes as well. I took the opportunity to
      do some refactoring of code in `TcDeriv`, especially the
      `mkNewTypeEqn` function, since it was bundling all of the logic for
      (1) deriving instances for newtypes and
      (2) `GeneralizedNewtypeDeriving`
      into one huge broth. `DerivingVia` reuses much of part (2), so that
      was factored out as much as possible.
      
      Bumps the Haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari, goldfire, alanz
      
      Subscribers: alanz, goldfire, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #15178
      
      Differential Revision: https://phabricator.haskell.org/D4684
      8ed8b037
  37. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored
      Poor DPH and its vectoriser have long been languishing; sadly it seems there is
      little chance that the effort will be rekindled. Every few years we discuss
      what to do with this mass of code and at least once we have agreed that it
      should be archived on a branch and removed from `master`. Here we do just that,
      eliminating heaps of dead code in the process.
      
      Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
      `primitive` submodules.
      
      Test Plan: Validate
      
      Reviewers: simonpj, simonmar, hvr, goldfire, alanz
      
      Reviewed By: simonmar
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4761
      faee23bb