1. 04 Feb, 2019 1 commit
  2. 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
  3. 22 Dec, 2018 1 commit
    • Ben Gamari's avatar
      testsuite: Remove expect_broken on readFail032 and readFail048 · 7e1d214f
      Ben Gamari authored
      As noted in #15662, these used to be broken on Darwin due to a Clang toolchain
      bug. However, this bug appears to be fixed in the Clang shipped with macOS
      Mojave. Unfortunately, we don't really have any way to only mark it as broken on
      certain operation system releases so I am just removing the expect_broken
      entirely.
      7e1d214f
  4. 01 Nov, 2018 1 commit
  5. 04 Oct, 2018 2 commits
    • Alec Theriault's avatar
      Improve generated `GHC.Prim` docs · feb8a671
      Alec Theriault authored
      Summary:
      * Extended `genprimcode` to generate Haddock-compatible deprecations,
        as well as displaying information about which functions are LLVM-only
        and which functions can fail with an unchecked exception.
      
      * Ported existing deprecations to the new format, and also added a
        deprecation on `par#` (see Trac #15227).
      
      * Emit an error on fixity/deprecation of builtins, unless we are
        processing the module in which that name is defined (see Trac #15233).
        That means the following is no longer accepted (outside of `GHC.Types`):
      
      ```
      infixr 7 :
      {-# DEPRECATED (:) "cons is deprecated" #-}
      ```
      
      * Generate `data (->) a b` with docs and fixity in `GHC.Prim`. This
        means: GHC can now parse `data (->) a b` and `infixr 0 ->` (only in
        `GHC.Prim`) and `genprimcode` can digest `primtype (->) a b` (See Trac
        #4861)
      
      as well as some misc fixes along the way.
      
      Reviewers: bgamari, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: RyanGlScott, rwbarton, mpickering, carter
      
      GHC Trac Issues: #15227, #15233, #4861
      
      Differential Revision: https://phabricator.haskell.org/D5167
      feb8a671
    • Vladislav Zavialov's avatar
      Parse the (!) type operator and allow type operators in existential context · bd789853
      Vladislav Zavialov authored
      Summary:
      Improve the way `(!)`, `(~)`, and other type operators are handled in the parser,
      fixing two issues at once:
      
      1. `(!)` can now be used as a type operator
         that respects fixity and precedence (#15457)
      2. Existential context of a data constructor
         no longer needs parentheses (#15675)
      
      In addition to that, with this patch it is now trivial to adjust precedence of
      the `{-# UNPACK #-}` pragma, as suggested in
      https://ghc.haskell.org/trac/ghc/ticket/14761#comment:7
      
      There was a small change to API Annotations. Before this patch, `(~)` was a
      strange special case that produced an annotation unlike any other type
      operator. After this patch, when `(~)` or `(!)` are used to specify strictness they
      produce AnnTilde and AnnBang annotations respectively, and when they are used
      as type operators, they produce no annotations.
      
      Test Plan: Validate
      
      Reviewers: simonpj, bgamari, alanz, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: RyanGlScott, rwbarton, mpickering, carter
      
      GHC Trac Issues: #15457, #15675
      
      Differential Revision: https://phabricator.haskell.org/D5180
      bd789853
  6. 21 Sep, 2018 2 commits
  7. 04 Sep, 2018 1 commit
  8. 21 Aug, 2018 1 commit
    • Ben Sklaroff's avatar
      Fix #line pragmas in nested comments · 02518f9d
      Ben Sklaroff authored
      When parsing a nested comment or nested doc comment in the lexer, if we
      see a line starting with '#' we attempt to parse a #line pragma. This
      fixes how ghc handles output of the C preproccesor (-cpp flag) when the
      original source has C comments or pragmas inside haskell comments.
      
      Updates haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #314
      
      Differential Revision: https://phabricator.haskell.org/D4934
      02518f9d
  9. 06 Jul, 2018 1 commit
  10. 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
  11. 07 Jun, 2018 1 commit
    • Ryan Scott's avatar
      Don't expose (~#), (~R#), (~P#) from GHC.Prim · 5926b6ed
      Ryan Scott authored
      Currently, the primitive `(~#)`, `(~R#)`, and `(~P#)` type
      constructors are wired in to be exported from `GHC.Prim`. This has
      some unfortunate consequences, however. It turns out that `(~#)` is
      actually a legal infix identifier, so users can make use of unboxed
      equalities in strange ways in user code (see #15209). The other two,
      `(~R#)` and `(~P#)`, can't be used in source code, but they can be
      observed with GHCi's `:browse` command, which is somewhat unnerving.
      
      The fix for both of these problems is simple: just don't wire them
      to be exported from `GHC.Prim`.
      
      Test Plan: make test TEST="T12023 T15209"
      
      Reviewers: bgamari, dfeuer
      
      Reviewed By: bgamari, dfeuer
      
      Subscribers: rwbarton, thomie, carter, dfeuer
      
      GHC Trac Issues: #12023, #15209
      
      Differential Revision: https://phabricator.haskell.org/D4801
      5926b6ed
  12. 19 Apr, 2018 1 commit
  13. 14 Mar, 2018 1 commit
    • Ömer Sinan Ağacan's avatar
      Slighly improve infix con app pattern errors · cb6d8589
      Ömer Sinan Ağacan authored
      Given this program:
      
          main = do
            f $ do
              a <- return 3
                c <- do
                return 5
      
      GHC previously gave this error message:
      
          Main.hs:2:7: error:
              Parse error in pattern: do a <- return 3 c
              Possibly caused by a missing 'do'?
            |
          2 |   f $ do
            |       ^^...
      
      What happened is GHC considered the whole `f $ do a <- return 3 c` as a
      pattern. When parsed as an expression it becomes an infix application of
      `($)`, and GHC checks left and right hand sides before checking if `($)`
      is a valid infix constructor name, and shows the first error it got.
      
      If instead we first check if the infix op is valid in pattern context,
      the error message becomes much clearer:
      
          Main.hs:2:3: error:
              Parse error in pattern: f $ do a <- return 3 c
              Possibly caused by a missing 'do'?
            |
          2 |   f $ do
            |   ^^^^^^...
      
      This may not entirely fix #11188 but I think it's an improvement.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #11188
      
      Differential Revision: https://phabricator.haskell.org/D4497
      cb6d8589
  14. 05 Mar, 2018 1 commit
    • 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
  15. 13 Feb, 2018 1 commit
    • Tao He's avatar
      Raise parse error for `data T where`. · 8936ab69
      Tao He authored
      Empty GADTs data declarations can't be identified in type checker. This
      patch adds additional checks in parser and raise a parse error when
      encounter empty GADTs declarations but extension `GADTs` is not enabled.
      
      Only empty declarations are checked in parser to avoid affecting
      existing
      error messages related to missing GADTs extension.
      
      This patch should fix issue 8258.
      Signed-off-by: Tao He's avatarHE, Tao <sighingnow@gmail.com>
      
      Test Plan: make test TEST="T8258 T8258NoGADTs"
      
      Reviewers: bgamari, mpickering, alanz, RyanGlScott
      
      Reviewed By: bgamari, RyanGlScott
      
      Subscribers: adamse, RyanGlScott, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #8258
      
      Differential Revision: https://phabricator.haskell.org/D4350
      8936ab69
  16. 01 Feb, 2018 2 commits
    • Tao He's avatar
      UnboxedTuples can't be used as constraints · ced9fbd3
      Tao He authored
      Fixes #14740.
      
      Test Plan: make test TEST="14740"
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14740
      
      Differential Revision: https://phabricator.haskell.org/D4359
      ced9fbd3
    • takano-akio's avatar
      Implement BlockArguments (#10843) · be84823b
      takano-akio authored
      This patch implements the BlockArguments extension, as proposed at
      https://github.com/ghc-proposals/ghc-proposals/pull/90. It also
      fixes #10855 as a side-effect.
      
      This patch adds a large number of shift-reduce conflicts to the parser.
      All of them concern the ambiguity as to where constructs like `if` and
      `let` end. Fortunately they are resolved correctly by preferring shift.
      
      The patch is based on @gibiansky's ArgumentDo implementation (D1219).
      
      Test Plan: ./validate
      
      Reviewers: goldfire, bgamari, alanz, mpickering
      
      Reviewed By: bgamari, mpickering
      
      Subscribers: Wizek, dfeuer, gibiansky, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #10843, #10855
      
      Differential Revision: https://phabricator.haskell.org/D4260
      be84823b
  17. 21 Jan, 2018 1 commit
    • Takenobu Tani's avatar
      Implement underscores in numeric literals (NumericUnderscores extension) · 4a13c5b1
      Takenobu Tani authored
      Implement the proposal of underscores in numeric literals.
      Underscores in numeric literals are simply ignored.
      
      The specification of the feature is available here:
      https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/000
      9-numeric-underscores.rst
      
      For a discussion of the various choices:
      https://github.com/ghc-proposals/ghc-proposals/pull/76
      
      Implementation detail:
      
      * Added dynamic flag
        * `NumericUnderscores` extension flag is added for this feature.
      
      * Alex "Regular expression macros" in Lexer.x
        * Add `@numspc` (numeric spacer) macro to represent multiple
          underscores.
        * Modify `@decimal`, `@decimal`, `@binary`, `@octal`, `@hexadecimal`,
          `@exponent`, and `@bin_exponent` macros to include `@numspc`.
      
      * Alex "Rules" in Lexer.x
        * To be simpler, we have only the definitions with underscores.
          And then we have a separate function (`tok_integral` and `tok_frac`)
          that validates the literals.
      
      * Validation functions in Lexer.x
        * `tok_integral` and `tok_frac` functions validate
          whether contain underscores or not.
          If `NumericUnderscores` extensions are not enabled,
          check that there are no underscores.
        * `tok_frac` function is created by merging `strtoken` and
          `init_strtoken`.
        * `init_strtoken` is deleted. Because it is no longer used.
      
      * Remove underscores from target literal string
        * `parseUnsignedInteger`, `readRational__`, and `readHexRational} use
          the customized `span'` function to remove underscores.
      
      * Added Testcase
        * testcase for NumericUnderscores enabled.
            NumericUnderscores0.hs and NumericUnderscores1.hs
        * testcase for NumericUnderscores disabled.
            NoNumericUnderscores0.hs and NoNumericUnderscores1.hs
        * testcase to invalid pattern for NumericUnderscores enabled.
            NumericUnderscoresFail0.hs and NumericUnderscoresFail1.hs
      
      Test Plan: `validate` including the above testcase
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: carter, rwbarton, thomie
      
      GHC Trac Issues: #14473
      
      Differential Revision: https://phabricator.haskell.org/D4235
      4a13c5b1
  18. 21 Dec, 2017 1 commit
    • Ryan Scott's avatar
      Fix #14588 by checking for more bang patterns · 9caf40e9
      Ryan Scott authored
      Summary:
      Commit 37299536
      inadvertently removed a check in the parser which rejected
      let-bindings with bang patterns, leading to #14588. This fixes it by
      creating a `hintBangPat` function to perform this check, and
      sprinkling it in the right places.
      
      Test Plan: make test TEST=T14588
      
      Reviewers: bgamari, alanz, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #14588
      
      Differential Revision: https://phabricator.haskell.org/D4270
      9caf40e9
  19. 25 Oct, 2017 1 commit
  20. 28 Jul, 2017 1 commit
    • Simon Peyton Jones's avatar
      Do not discard insolubles in implications · 452755de
      Simon Peyton Jones authored
      Trac #14000 showed up two errors
      
      * In TcRnTypes.dropInsolubles we dropped all implications, which
        might contain the very insolubles we wanted to keep.  This was
        an outright error, and is why the out-of-scope error was actually
        lost altogether in Trac #14000
      
      * In TcSimplify.simplifyInfer, if there are definite (insoluble)
        errors, it's better to suppress the following ambiguity test,
        because the type may be bogus anyway.  See TcSimplify
        Note [Quantification with errors].  This fix seems a bit clunky,
        but it'll do for now.
      452755de
  21. 11 Jul, 2017 1 commit
    • Ryan Scott's avatar
      Fix #13948 by being pickier about when to suggest DataKinds · ba46e63f
      Ryan Scott authored
      Commit 343cb32d (#13568) made GHC a bit
      too cavalier in suggesting when data constructors are in scope (and
      suggesting the use of `DataKinds`). This tones down the suggestions so
      that `DataKinds` is only suggested if a data constructor of that name is
      actually in scope (previously, it would always suggest, even if it was
      out of scope).
      
      Fixes #13948.
      
      Test Plan: ./validate
      
      Reviewers: mpickering, austin, bgamari
      
      Reviewed By: mpickering
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13948
      
      Differential Revision: https://phabricator.haskell.org/D3719
      ba46e63f
  22. 15 May, 2017 1 commit
  23. 11 May, 2017 1 commit
    • mrkgnao's avatar
      Fix incorrect ambiguity error on identically-named data constructors · 1381c142
      mrkgnao authored
      Given multiple in-scope constructors with the same name, say `A`, and a
      function of type `A -> Int`, say, the compiler reports both a "type `A`
      is not in scope" and (incorrectly) an ambiguity error. The latter
      shouldn't be there if `DataKinds` isn't enabled.
      
      This issue was recommended to me by @mpickering as a suitable first
      task, and the fix was also outlined in the original Trac ticket. It
      involved a simple reordering of the steps taken in `lookup_demoted` in
      `RnEnv.hs`. The fix is to make the `DataKinds` check happen earlier,
      ensuring that the ambiguity check doesn't happen at all if we know the
      constructors couldn't have been promoted.
      Signed-off-by: mrkgnao's avatarSoham Chowdhury <chow.soham@gmail.com>
      
      Reviewers: mpickering, austin, bgamari
      
      Reviewed By: mpickering, bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13568
      
      Differential Revision: https://phabricator.haskell.org/D3547
      1381c142
  24. 29 Mar, 2017 1 commit
  25. 13 Mar, 2017 1 commit
  26. 10 Mar, 2017 2 commits
    • Simon Peyton Jones's avatar
      Improve error messages for skolems · 48d1866e
      Simon Peyton Jones authored
      In error messages like this
          • Couldn't match type ‘c’ with ‘f0 (a -> b)’
            ‘c’ is a rigid type variable bound by
              the type signature for:
                f :: ((a -> b) -> b) -> forall c. c -> a
      
      we need to take case both to actually show that 'forall c',
      and to make sure that its name lines with the 'c' in the
      error message.
      
      This has been shaky for some time, and this commit puts it on solid
      ground.  See TcRnTypes: Note [SigSkol SkolemInfo]
      
      The main changes are
      
      * SigSkol gets an extra field that records the way in which the
        type signature was skolemised.
      
      * The type in SigSkol is now the /un/-skolemised version
      
      * pprSkolemInfo uses the info to make the tidy type line up
        nicely
      
      Lots of error message wibbles!
      48d1866e
    • Simon Peyton Jones's avatar
      Fix TcSimplify.decideQuantification for kind variables · 7e96526a
      Simon Peyton Jones authored
      TcSimplify.decideQuantification was doing the Wrong Thing when
      "growing" the type variables to quantify over. We were trying to do
      this on a tyvar set where we'd split off the dependent type varaibles;
      and we just got it wrong.  A kind variable wasn't being generalised
      properly, with confusing knock on consequences.
      
      All this led to Trac #13371 and Trac #13393.
      
      This commit tidies it all up:
      
      * The type TcDepVars is renamed as CandidateQTvs;
        and splitDepVarsOfType to candidateQTyVarsOfType
      
      * The code in TcSimplify.decideQuantification is simpler.
        It no longer does the tricky "grow" stuff over TcDepVars.
        Instead it use ordinary VarSets (thereby eliminating the
        nasty growThetaTyVarsDSet) and uses that to filter the
        result of candidateQTyVarsOfType.
      
      * I documented that candidateQTyVarsOfType returns the type
        variables in a good order in which to quantify, and rewrote
        it to use an accumulator pattern, so that we would predicatably
        get left-to-right ordering.
      
      In doing all this I also made UniqDFM behave a little more nicely:
      
      * When inserting an element that is there already, keep the old tag,
        while still overwriting with the new value.
      
      * This means that when doing udfmToList we get back elements in the
        order they were originally inserted, rather than in reverse order.
      
      It's not a big deal, but in a subsequent commit I use it to improve
      the order of type variables in inferred types.
      
      All this led to a lot of error message wibbles:
       - changing the order of quantified variables
       - changing the order in which instances are listed in GHCi
       - changing the tidying of variables in typechecker erors
      
      There's a submodule update for 'array' because one of its tests
      has an error-message change.
      
      I may not have associated all of them with the correct commit.
      7e96526a
  27. 06 Mar, 2017 1 commit
  28. 03 Mar, 2017 3 commits
  29. 09 Feb, 2017 1 commit
  30. 21 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      A collection of type-inference refactorings. · 3f5673f3
      Simon Peyton Jones authored
      This patch does a raft of useful tidy-ups in the type checker.
      I've been meaning to do this for some time, and finally made
      time to do it en route to ICFP.
      
      1. Modify TcType.ExpType to make a distinct data type,
         InferResult for the Infer case, and consequential
         refactoring.
      
      2. Define a new function TcUnify.fillInferResult, to fill in
         an InferResult. It uses TcMType.promoteTcType to promote
         the type to the level of the InferResult.
         See TcMType Note [Promoting a type]
         This refactoring is in preparation for an improvement
         to typechecking pattern bindings, coming next.
      
         I flirted with an elaborate scheme to give better
         higher rank inference, but it was just too complicated.
         See TcMType Note [Promotion and higher rank types]
      
      3. Add to InferResult a new field ir_inst :: Bool to say
         whether or not the type used to fill in the
         InferResult should be deeply instantiated.  See
         TcUnify Note [Deep instantiation of InferResult].
      
      4. Add a TcLevel to SkolemTvs. This will be useful generally
      
          - it's a fast way to see if the type
            variable escapes when floating (not used yet)
      
          - it provides a good consistency check when updating a
            unification variable (TcMType.writeMetaTyVarRef, the
            level_check_ok check)
      
         I originally had another reason (related to the flirting
         in (2), but I left it in because it seems like a step in
         the right direction.
      
      5. Reduce and simplify the plethora of uExpType,
         tcSubType and related functions in TcUnify.  It was
         such an opaque mess and it's still not great, but it's
         better.
      
      6. Simplify the uo_expected field of TypeEqOrigin.  Richard
         had generatlised it to a ExpType, but it was almost always
         a Check type.  Now it's back to being a plain TcType which
         is much, much easier.
      
      7. Improve error messages by refraining from skolemisation when
         it's clear that there's an error: see
         TcUnify Note [Don't skolemise unnecessarily]
      
      8. Type.isPiTy and isForAllTy seem to be missing a coreView check,
         so I added it
      
      9. Kill off tcs_used_tcvs.  Its purpose is to track the
         givens used by wanted constraints.  For dictionaries etc
         we do that via the free vars of the /bindings/ in the
         implication constraint ic_binds.  But for coercions we
         just do update-in-place in the type, rather than
         generating a binding.  So we need something analogous to
         bindings, to track what coercions we have added.
      
         That was the purpose of tcs_used_tcvs.  But it only
         worked for a /single/ iteration, whereas we may have
         multiple iterations of solving an implication.  Look
         at (the old) 'setImplicationStatus'.  If the constraint
         is unsolved, it just drops the used_tvs on the floor.
         If it becomes solved next time round, we'll pick up
         coercions used in that round, but ignore ones used in
         the first round.
      
         There was an outright bug.  Result = (potentialy) bogus
         unused-constraint errors.  Constructing a case where this
         actually happens seems quite trick so I did not do so.
      
         Solution: expand EvBindsVar to include the (free vars of
         the) coercions, so that the coercions are tracked in
         essentially the same way as the bindings.
      
         This turned out to be much simpler.  Less code, more
         correct.
      
      10. Make the ic_binds field in an implication have type
            ic_binds :: EvBindsVar
          instead of (as previously)
             ic_binds :: Maybe EvBindsVar
          This is notably simpler, and faster to use -- less
          testing of the Maybe.  But in the occaional situation
          where we don't have anywhere to put the bindings, the
          belt-and-braces error check is lost.  So I put it back
          as an ASSERT in 'setImplicationStatus' (see the use of
          'termEvidenceAllowed')
      
      All these changes led to quite bit of error message wibbling
      3f5673f3
  31. 01 Oct, 2016 1 commit
    • Ryan Scott's avatar
      Implement deriving strategies · 9e862765
      Ryan Scott authored
      Allows users to explicitly request which approach to `deriving` to use
      via keywords, e.g.,
      
      ```
      newtype Foo = Foo Bar
        deriving Eq
        deriving stock    Ord
        deriving newtype Show
      ```
      
      Fixes #10598. Updates haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin,
      erikd, simonmar
      
      Reviewed By: alanz, bgamari, simonpj
      
      Subscribers: thomie, mpickering, oerjan
      
      Differential Revision: https://phabricator.haskell.org/D2280
      
      GHC Trac Issues: #10598
      9e862765
  32. 20 Jun, 2016 1 commit
  33. 15 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Major patch to introduce TyConBinder · e368f326
      Simon Peyton Jones authored
      Before this patch, following the TypeInType innovations,
      each TyCon had two lists:
        - tyConBinders :: [TyBinder]
        - tyConTyVars  :: [TyVar]
      
      They were in 1-1 correspondence and contained
      overlapping information.  More broadly, there were many
      places where we had to pass around this pair of lists,
      instead of a single list.
      
      This commit tidies all that up, by having just one list of
      binders in a TyCon:
      
        - tyConBinders :: [TyConBinder]
      
      The new data types look like this:
      
        Var.hs:
           data TyVarBndr tyvar vis = TvBndr tyvar vis
           data VisibilityFlag = Visible | Specified | Invisible
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
      
        TyCon.hs:
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
      
           data TyConBndrVis
             = NamedTCB VisibilityFlag
             | AnonTCB
      
        TyCoRep.hs:
           data TyBinder
             = Named TyVarBinder
             | Anon Type
      
      Note that Var.TyVarBdr has moved from TyCoRep and has been
      made polymorphic in the tyvar and visiblity fields:
      
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
              -- Used in ForAllTy
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
              -- Used in TyCon
      
           type IfaceForAllBndr  = TyVarBndr IfaceTvBndr VisibilityFlag
           type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
               -- Ditto, in interface files
      
      There are a zillion knock-on changes, but everything
      arises from these types.  It was a bit fiddly to get the
      module loops to work out right!
      
      Some smaller points
      ~~~~~~~~~~~~~~~~~~~
      * Nice new functions
          TysPrim.mkTemplateKiTyVars
          TysPrim.mkTemplateTyConBinders
        which help you make the tyvar binders for dependently-typed
        TyCons.  See comments with their definition.
      
      * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
        was making an assumption about the order of the kind variables in the
        kind of GHC.Generics.(:.:).  I fixed this; see TcGenGenerics.mkComp.
      e368f326
  34. 19 May, 2016 1 commit