1. 08 Feb, 2019 1 commit
  2. 15 Jan, 2019 1 commit
  3. 06 Jan, 2019 1 commit
  4. 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
  5. 24 Nov, 2018 1 commit
  6. 29 Oct, 2018 1 commit
    • Tobias Dammers's avatar
      Finish fix for #14880. · 5e45ad10
      Tobias Dammers authored
      The real change that fixes the ticket is described in
      Note [Naughty quantification candidates] in TcMType.
      
      Fixing this required reworking candidateQTyVarsOfType, the function
      that extracts free variables as candidates for quantification.
      One consequence is that we now must be more careful when quantifying:
      any skolems around must be quantified manually, and quantifyTyVars
      will now only quantify over metavariables. This makes good sense,
      as skolems are generally user-written and are listed in the AST.
      
      As a bonus, we now have more control over the ordering of such
      skolems.
      
      Along the way, this commit fixes #15711 and refines the fix
      to #14552 (by accepted a program that was previously rejected,
      as we can now accept that program by zapping variables to Any).
      
      This commit also does a fair amount of rejiggering kind inference
      of datatypes. Notably, we now can skip the generalization step
      in kcTyClGroup for types with CUSKs, because we get the
      kind right the first time. This commit also thus fixes #15743 and
       #15592, which both concern datatype kind generalisation.
      (#15591 is also very relevant.) For this aspect of the commit, see
      Note [Required, Specified, and Inferred in types] in TcTyClsDecls.
      
      Test cases: dependent/should_fail/T14880{,-2},
                  dependent/should_fail/T15743[cd]
                  dependent/should_compile/T15743{,e}
                  ghci/scripts/T15743b
                  polykinds/T15592
                  dependent/should_fail/T15591[bc]
                  ghci/scripts/T15591
      5e45ad10
  7. 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
  8. 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
  9. 28 Aug, 2018 1 commit
  10. 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
  11. 10 Jul, 2018 1 commit
  12. 20 Jun, 2018 1 commit
    • Ryan Scott's avatar
      Remove HsEqTy and XEqTy · b9483981
      Ryan Scott authored and Ben Gamari's avatar Ben Gamari committed
      After commit d650729f, the
      `HsEqTy` constructor of `HsType` is essentially dead code. Given that
      we want to remove `HsEqTy` anyway as a part of #10056 (comment:27),
      let's just rip it out.
      
      Bumps the haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #10056
      
      Differential Revision: https://phabricator.haskell.org/D4876
      b9483981
  13. 17 Jun, 2018 1 commit
  14. 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, ...
      d650729f
  15. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      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
  16. 27 Apr, 2018 1 commit
    • Alan Zimmerman's avatar
      TTG : complete for balance of hsSyn AST · c3823cba
      Alan Zimmerman authored
      Summary:
      - remove PostRn/PostTc fields
      - remove the HsVect In/Out distinction for Type, Class and Instance
      - remove PlaceHolder in favour of NoExt
      - Simplify OutputableX constraint
      
      Updates haddock submodule
      
      Test Plan: ./validate
      
      Reviewers: goldfire, bgamari
      
      Subscribers: goldfire, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4625
      c3823cba
  17. 19 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14710 with more validity checks during renaming · 447d1264
      Ryan Scott authored
      Summary:
      #14710 revealed two unfortunate regressions related to kind
      polymorphism that had crept in in recent GHC releases:
      
      1. While GHC was able to catch illegal uses of kind polymorphism
         (i.e., if `PolyKinds` wasn't enabled) in limited situations, it
         wasn't able to catch kind polymorphism of the following form:
      
      ```lang=haskell
      f :: forall a. a -> a
      f x = const x g
        where
          g :: Proxy (x :: a)
          g = Proxy
      ```
      
      Note that the variable `a` is being used as a kind variable in the
      type signature of `g`, but GHC happily accepts it, even without
      the use of `PolyKinds`.
      
      2. If you have `PolyKinds` (but not `TypeInType`) enabled, then GHC
         incorrectly accepts the following definition:
      
      ```lang=haskell
      f :: forall k (a :: k). Proxy a
      f = Proxy
      ```
      
      Even though `k` is explicitly bound and then later used as a kind
      variable within the same telescope.
      
      This patch fixes these two bugs as follows:
      
      1. Whenever we rename any `HsTyVar`, we check if the following three
         criteria are met:
      
         (a) It's a type variable
         (b) It's used at the kind level
         (c) `PolyKinds` is not enabled
      
         If so, then we have found an illegal use of kind polymorphism, so
         throw an error.
      
         This check replaces the `checkBadKindBndrs` function, which could
         only catch illegal uses of kind polymorphism in very limited
         situations (when the bad kind variable happened to be implicitly
         quantified in the same type signature).
      
      2. In `extract_hs_tv_bndrs`, we must error if `TypeInType` is not
         enabled and either of the following criteria are met:
      
         (a) An explicitly bound type variable is used in kind position
             in the body of a `forall` type.
         (b) An explicitly bound type variable is used in kind position
             in the kind of a bound type variable in a `forall` type.
      
         `extract_hs_tv_bndrs` was checking (a), but not (b). Easily fixed.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, bgamari, hvr
      
      Reviewed By: simonpj
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #14710
      
      Differential Revision: https://phabricator.haskell.org/D4554
      447d1264
  18. 09 Apr, 2018 1 commit
  19. 23 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Allow PartialTypeSignatures in standalone deriving contexts · affdea82
      Ryan Scott authored
      Summary:
      At its core, this patch is a simple tweak that allows a user
      to write:
      
      ```lang=haskell
      deriving instance _ => Eq (Foo a)
      ```
      
      Which is functionally equivalent to:
      
      ```lang=haskell
      data Foo a = ...
        deriving Eq
      ```
      
      But with the added flexibility that `StandaloneDeriving` gives you
      (namely, the ability to use it anywhere, not just in the same module
      that `Foo` was declared in). This fixes #13324, and should hopefully
      address a use case brought up in #10607.
      
      Currently, only the use of a single, extra-constraints wildcard is
      permitted in a standalone deriving declaration. Any other wildcard
      is rejected, so things like
      `deriving instance (Eq a, _) => Eq (Foo a)` are currently forbidden.
      
      There are quite a few knock-on changes brought on by this change:
      
      * The `HsSyn` type used to represent standalone-derived instances
        was previously `LHsSigType`, which isn't sufficient to hold
        wildcard types. This needed to be changed to `LHsSigWcType` as a
        result.
      
      * Previously, `DerivContext` was a simple type synonym for
        `Maybe ThetaType`, under the assumption that you'd only ever be in
        the `Nothing` case if you were in a `deriving` clause. After this
        patch, that assumption no longer holds true, as you can also be
        in this situation with standalone deriving when an
        extra-constraints wildcard is used.
      
        As a result, I changed `DerivContext` to be a proper datatype that
        reflects the new wrinkle that this patch adds, and plumbed this
        through the relevant parts of `TcDeriv` and friends.
      
      * Relatedly, the error-reporting machinery in `TcErrors` also assumed
        that if you have any unsolved constraints in a derived instance,
        then you should be able to fix it by switching over to standalone
        deriving. This was always sound advice before, but with this new
        feature, it's possible to have unsolved constraints even when
        you're standalone-deriving something!
      
        To rectify this, I tweaked some constructors of `CtOrigin` a bit
        to reflect this new subtlety.
      
      This requires updating the Haddock submodule. See my fork at
      https://github.com/RyanGlScott/haddock/commit/067d52fd4be15a1842cbb05f42d9d482de0ad3a7
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #13324
      
      Differential Revision: https://phabricator.haskell.org/D4383
      affdea82
  20. 05 Mar, 2018 2 commits
    • Simon Peyton Jones's avatar
      Simplify rnLHsInstType · 1c062b79
      Simon Peyton Jones authored
      This patch is preparatory for the main fix for Trac #13324
      
      Here, we simplify rnLHsInstType so that it does not try
      to figure out the class name.  This turns out to have a good
      (rather than bad) effect on error messages, and it prepares
      the way for the main event.
      
      Plus, less code!
      1c062b79
    • Simon Peyton Jones's avatar
      Wombling around in Trac #14808 · e7653bc3
      Simon Peyton Jones authored
      Comment:4 in Trac #14808 explains why I'm unhappy with the current
      state of affairs -- at least the lack of documentation.
      
      This smallpatch does nothing major:
      
      * adds comments
      * uses existing type synonyms more (notably FreeKiTyVarsWithDups)
      * adds another test case to T14808
      e7653bc3
  21. 19 Dec, 2017 1 commit
  22. 07 Dec, 2017 1 commit
    • Simon Peyton Jones's avatar
      Refactor ConDecl: Trac #14529 · fa29df02
      Simon Peyton Jones authored
      This patch refactors HsDecls.ConDecl.  Specifically
      
      * ConDeclGADT was horrible, with all the information hidden
        inside con_res_ty.  Now it's kept separate, as it should be.
      
      * ConDeclH98: use [LHsTyVarBndr] instead of LHsQTyVars for the
        existentials. There is no implicit binding here.
      
      * Add a field con_forall to both ConDeclGADT and ConDeclH98
        which says if there is an explicit user-written forall.
      
      * Field renamings in ConDecl
           con_cxt     to con_mb_cxt
           con_details to con_args
      
      There is an accompanying submodule update to Haddock.
      
      Also the following change turned out to remove a lot of clutter:
      
      * add a smart constructor for HsAppsTy, namely mkHsAppsTy,
        and use it consistently. This avoids a lot of painful pattern
        matching for the common singleton case.
      
      Two api-annotation tests (T10278, and T10399) are broken, hence marking
      them as expect_broken(14529).  Alan is going to fix them, probably by
      changing the con_forall field to
         con_forall :: Maybe SrcSpan
      instead of Bool
      fa29df02
  23. 21 Nov, 2017 1 commit
    • Ben Gamari's avatar
      Revert "trees that grow" work · 314bc314
      Ben Gamari authored
      As documented in #14490, the Data instances currently blow up
      compilation time by too much to stomach. Alan will continue working on
      this in a branch and we will perhaps merge to 8.2 before 8.2.1 to avoid
      having to perform painful cherry-picks in 8.2 minor releases.
      
      Reverts haddock submodule.
      
      This reverts commit 47ad6578.
      This reverts commit e3ec2e7a.
      This reverts commit 438dd1cb.
      This reverts commit 0ff152c9.
      314bc314
  24. 14 Nov, 2017 1 commit
  25. 11 Nov, 2017 1 commit
  26. 08 Nov, 2017 1 commit
  27. 07 Nov, 2017 2 commits
  28. 12 Oct, 2017 1 commit
    • Simon Peyton Jones's avatar
      Do not quantify over deriving clauses · 82b77ec3
      Simon Peyton Jones authored
      Trac #14331 showed that in a data type decl like
      
         data D = D deriving (C (a :: k))
      
      we were quantifying D over the 'k' in the deriving clause.  Yikes.
      
      Easily fixed, by deleting code in RnTypes.extractDataDefnKindVars
      
      See the discussion on the ticket, esp comment:8.
      82b77ec3
  29. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored and Ben Gamari's avatar Ben Gamari committed
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  30. 05 Sep, 2017 2 commits
    • Ryan Scott's avatar
      Implicitly bind kind variables in type family instance RHSes when it's sensible · 0829821a
      Ryan Scott authored
      Summary:
      Before, there was a discrepancy in how GHC renamed type synonyms as
      opposed to type family instances. That is, GHC would accept definitions like
      this one:
      
      ```lang=haskell
      type T = (Nothing :: Maybe a)
      ```
      
      However, it would not accept a very similar type family instance:
      
      ```lang=haskell
      type family   T :: Maybe a
      type instance T = (Nothing :: Maybe a)
      ```
      
      The primary goal of this patch is to bring the renaming of type family
      instances up to par with that of type synonyms, causing the latter definition
      to be accepted, and fixing #14131.
      
      In particular, we now allow kind variables on the right-hand sides of type
      (and data) family instances to be //implicitly// bound by LHS type (or kind)
      patterns (as opposed to type variables, which must always be explicitly
      bound by LHS type patterns only). As a consequence, this allows programs
      reported in #7938 and #9574 to typecheck, whereas before they would
      have been rejected.
      
      Implementation-wise, there isn't much trickery involved in making this happen.
      We simply need to bind additional kind variables from the RHS of a type family
      in the right place (in particular, see `RnSource.rnFamInstEqn`, which has
      undergone a minor facelift).
      
      While doing this has the upside of fixing #14131, it also made it easier to
      trigger #13985, so I decided to fix that while I was in town. This was
      accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13985, #14131
      
      Differential Revision: https://phabricator.haskell.org/D3872
      0829821a
    • Ryan Scott's avatar
      Fix egregious duplication of vars in RnTypes · b9ac9e05
      Ryan Scott authored and Ben Gamari's avatar Ben Gamari committed
      `RnTypes` contains a fairly intricate algorithm to extract
      the kind and type variables of an HsType. This algorithm carefully
      maintains the separation between type variables and kind variables
      so that the difference between `-XPolyKinds` and `-XTypeInType` can
      be respected.
      
      But after doing all this, `rmDupsInRdrTyVars` stupidly just
      concatenated the lists of type and kind variables at the end. If a
      variable were used as both a type and a kind, the algorithm would
      produce *both*! This led to all kinds of problems, including #13988.
      
      This is mostly Richard Eisenberg's patch. The only original
      contribution I made was adapting call sites of `rnImplicitBndrs` to
      work with the new definition of `rmDupsInRdrTyVars`. That is,
      `rnImplicitBndrs` checks for variables that are illegally used in
      both type and kind positions without using `-XTypeInType`, but in
      order to check this, one cannot have filtered duplicate variables out
      before passing them to `rnImplicitBndrs`. To accommodate for this, I
      needed to concoct variations on the existing `extract-` functions in
      `RnTypes` which do not remove duplicates, and use those near
      `rnImplicitBndrs` call sites.
      
      test case: ghci/scripts/T13988
      
      Test Plan: make test TEST=T13988
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13988
      
      Differential Revision: https://phabricator.haskell.org/D3902
      b9ac9e05
  31. 30 Aug, 2017 1 commit
    • Simon Peyton Jones's avatar
      Add comments to RnTypes · 628b6669
      Simon Peyton Jones authored
      These comments clarify the details of:
      
        commit 0257dacf
        Author: Simon Peyton Jones <simonpj@microsoft.com>
        Date:   Mon Aug 28 14:20:02 2017 +0100
      
            Refactor bindHsQTyVars and friends
      628b6669
  32. 29 Aug, 2017 1 commit
    • Simon Peyton Jones's avatar
      Refactor bindHsQTyVars and friends · 0257dacf
      Simon Peyton Jones authored
      This work was triggered by Trac #13738, which revealed to me that
      the code RnTypes.bindHsQTyVars and bindLHsTyVarBndrs was a huge
      tangled mess -- and outright wrong on occasion as the ticket showed.
      
      The big problem was that bindLHsTyVarBndrs (which is invoked at every
      HsForAll, including nested higher rank ones) was attempting to bind
      implicit kind variables, which it has absolutely no busineess doing.
      Imlicit kind quantification is done at the outside only, in fact
      precisely where we have HsImplicitBndrs or LHsQTyVars (which also
      has implicit binders).
      
      Achieving this move was surprisingly hard, because more and more
      barnacles had accreted aroud the original mistake.  It's much
      much better now.
      
      Summary of changes.  Almost all the action is in RnTypes.
      
      * Implicit kind variables are bound only by
        - By bindHsQTyVars, which deals with LHsQTyVars
        - By rnImplicitBndrs, which deals with HsImplicitBndrs
      
      * bindLHsTyVarBndrs, and bindLHsTyVarBndr are radically simplified.
        They simply does far less, and have lots their forest of
        incomprehensible accumulating parameters.  (To be fair, some of
        the code in bindLHsTyVarBndrs just moved to bindHsQTyVars, but
        in much more perspicuous form.)
      
      * The code that checks if a variable appears in both a kind and
        a type (triggering RnTypes.mixedVarsErr) was bizarre.  E.g.
        we had this in RnTypes.extract_hs_tv_bndrs
             ; check_for_mixed_vars bndr_kvs acc_tvs
             ; check_for_mixed_vars bndr_kvs body_tvs
             ; check_for_mixed_vars body_tvs acc_kvs
             ; check_for_mixed_vars body_kvs acc_tvs
             ; check_for_mixed_vars locals body_kvs
        I cleaned all this up; now we check for mixed use at binding
        sites only.
      
      * Checks for "Variable used as a kind before being bound", like
           data T (a :: k) k = rhs
        now just show up straightforwardly as "k is not in scope".
        See Note [Kind variable ordering]
      
      * There are some knock-on simplifications in RnSource.
      0257dacf
  33. 12 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Use NonEmpty lists to represent lists of duplicate elements · 7d699782
      Ryan Scott authored
      Summary:
      Three functions in `ListSetOps` which compute duplicate elements
      represent lists of duplicates of `[a]`. This is a really bad way to go about
      things, because these lists are guaranteed to always have at least one element
      (the "representative" of the duplicates), and several places in the GHC API
      call `head` (a partial function) on these lists of duplicates to retrieve the
      representative.
      
      This changes the representation of duplicates to `NonEmpty` lists instead,
      which allow for many partial uses of `head` to be made total.
      
      Fixes #13823.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie
      
      GHC Trac Issues: #13823
      
      Differential Revision: https://phabricator.haskell.org/D3823
      7d699782
  34. 31 Jul, 2017 1 commit
  35. 27 Jul, 2017 1 commit
  36. 11 Jul, 2017 1 commit
  37. 21 Jun, 2017 1 commit