1. 11 Jan, 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. 19 Dec, 2018 1 commit
  4. 11 Dec, 2018 1 commit
  5. 29 Nov, 2018 1 commit
    • Simon Peyton Jones's avatar
      Taming the Kind Inference Monster · 2257a86d
      Simon Peyton Jones authored
      My original goal was (Trac #15809) to move towards using level numbers
      as the basis for deciding which type variables to generalise, rather
      than searching for the free varaibles of the environment.  However
      it has turned into a truly major refactoring of the kind inference
      engine.
      
      Let's deal with the level-numbers part first:
      
      * Augment quantifyTyVars to calculate the type variables to
        quantify using level numbers, and compare the result with
        the existing approach.  That is; no change in behaviour,
        just a WARNing if the two approaches give different answers.
      
      * To do this I had to get the level number right when calling
        quantifyTyVars, and this entailed a bit of care, especially
        in the code for kind-checking type declarations.
      
      * However, on the way I was able to eliminate or simplify
        a number of calls to solveEqualities.
      
      This work is incomplete: I'm not /using/ level numbers yet.
      When I subsequently get rid of any remaining WARNings in
      quantifyTyVars, that the level-number answers differ from
      the current answers, then I can rip out the current
      "free vars of the environment" stuff.
      
      Anyway, this led me into deep dive into kind inference for type and
      class declarations, which is an increasingly soggy part of GHC.
      Richard already did some good work recently in
      
         commit 5e45ad10
         Date:   Thu Sep 13 09:56:02 2018 +0200
      
          Finish fix for #14880.
      
          The real change that fixes the ticket is described in
          Note [Naughty quantification candidates] in TcMType.
      
      but I kept turning over stones. So this patch has ended up
      with a pretty significant refactoring of that code too.
      
      Kind inference for types and classes
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      * Major refactoring in the way we generalise the inferred kind of
        a TyCon, in kcTyClGroup.  Indeed, I made it into a new top-level
        function, generaliseTcTyCon.  Plus a new Note to explain it
        Note [Inferring kinds for type declarations].
      
      * We decided (Trac #15592) not to treat class type variables specially
        when dealing with Inferred/Specified/Required for associated types.
        That simplifies things quite a bit. I also rewrote
        Note [Required, Specified, and Inferred for types]
      
      * Major refactoring of the crucial function kcLHsQTyVars:
        I split it into
             kcLHsQTyVars_Cusk  and  kcLHsQTyVars_NonCusk
        because the two are really quite different. The CUSK case is
        almost entirely rewritten, and is much easier because of our new
        decision not to treat the class variables specially
      
      * I moved all the error checks from tcTyClTyVars (which was a bizarre
        place for it) into generaliseTcTyCon and/or the CUSK case of
        kcLHsQTyVars.  Now tcTyClTyVars is extremely simple.
      
      * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed
        now there is no difference between tcImplicitTKBndrs and
        kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs.
        Same for kc/tcExplicitTKBndrs.  None of them monkey with level
        numbers, nor build implication constraints.  scopeTyVars is gone
        entirely, as is kcLHsQTyVarBndrs. It's vastly simpler.
      
        I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of
        the bnew bindExplicitTKBndrs.
      
      Quantification
      ~~~~~~~~~~~~~~
      * I now deal with the "naughty quantification candidates"
        of the previous patch in candidateQTyVars, rather than in
        quantifyTyVars; see Note [Naughty quantification candidates]
        in TcMType.
      
        I also killed off closeOverKindsCQTvs in favour of the same
        strategy that we use for tyCoVarsOfType: namely, close over kinds
        at the occurrences.
      
        And candidateQTyVars no longer needs a gbl_tvs argument.
      
      * Passing the ContextKind, rather than the expected kind itself,
        to tc_hs_sig_type_and_gen makes it easy to allocate the expected
        result kind (when we are in inference mode) at the right level.
      
      Type families
      ~~~~~~~~~~~~~~
      * I did a major rewrite of the impenetrable tcFamTyPats. The result
        is vastly more comprehensible.
      
      * I got rid of kcDataDefn entirely, quite a big function.
      
      * I re-did the way that checkConsistentFamInst works, so
        that it allows alpha-renaming of invisible arguments.
      
      * The interaction of kind signatures and family instances is tricky.
          Type families: see Note [Apparently-nullary families]
          Data families: see Note [Result kind signature for a data family instance]
                         and Note [Eta-reduction for data families]
      
      * The consistent instantation of an associated type family is tricky.
        See Note [Checking consistent instantiation] and
            Note [Matching in the consistent-instantation check]
        in TcTyClsDecls.  It's now checked in TcTyClsDecls because that is
        when we have the relevant info to hand.
      
      * I got tired of the compromises in etaExpandFamInst, so I did the
        job properly by adding a field cab_eta_tvs to CoAxBranch.
        See Coercion.etaExpandCoAxBranch.
      
      tcInferApps and friends
      ~~~~~~~~~~~~~~~~~~~~~~~
      * I got rid of the mysterious and horrible ClsInstInfo argument
        to tcInferApps, checkExpectedKindX, and various checkValid
        functions.  It was horrible!
      
      * I got rid of [Type] result of tcInferApps.  This list was used
        only in tcFamTyPats, when checking the LHS of a type instance;
        and if there is a cast in the middle, the list is meaningless.
        So I made tcInferApps simpler, and moved the complexity
        (not much) to tcInferApps.
      
        Result: tcInferApps is now pretty comprehensible again.
      
      * I refactored the many function in TcMType that instantiate skolems.
      
      Smaller things
      
      * I rejigged the error message in checkValidTelescope; I think it's
        quite a bit better now.
      
      * checkValidType was not rejecting constraints in a kind signature
           forall (a :: Eq b => blah). blah2
        That led to further errors when we then do an ambiguity check.
        So I make checkValidType reject it more aggressively.
      
      * I killed off quantifyConDecl, instead calling kindGeneralize
        directly.
      
      * I fixed an outright bug in tyCoVarsOfImplic, where we were not
        colleting the tyvar of the kind of the skolems
      
      * Renamed ClsInstInfo to AssocInstInfo, and made it into its
        own data type
      
      * Some fiddling around with pretty-printing of family
        instances which was trickier than I thought.  I wanted
        wildcards to print as plain "_" in user messages, although
        they each need a unique identity in the CoAxBranch.
      
      Some other oddments
      
      * Refactoring around the trace messages from reportUnsolved.
      * A bit of extra tc-tracing in TcHsSyn.commitFlexi
      
      This patch fixes a raft of bugs, and includes tests for them.
      
       * #14887
       * #15740
       * #15764
       * #15789
       * #15804
       * #15817
       * #15870
       * #15874
       * #15881
      2257a86d
  6. 24 Nov, 2018 1 commit
  7. 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
  8. 15 Nov, 2018 1 commit
    • Simon Peyton Jones's avatar
      Smarter HsType pretty-print for promoted datacons · ae2c9b40
      Simon Peyton Jones authored
      Fix Trac #15898, by being smarter about when to print
      a space before a promoted data constructor, in a HsType.
      I had to implement a mildly tiresome function
          HsType.lhsTypeHasLeadingPromotionQuote
      It has multiple cases, of course, but it's very simple.
      
      The patch improves the error-message output in a bunch of
      cases, and (to my surprise) actually fixes a bug in the
      output of T14343 (Trac #14343), thus
      
        -  In the expression: _ :: Proxy '('( 'True,  'False),  'False)
        +  In the expression: _ :: Proxy '( '( 'True, 'False), 'False)
      
      I discovered that there were two copies of the PromotionFlag
      type (a boolean, with helpfully named data cons), one in
      IfaceType and one in HsType.  So I combined into one,
      PromotionFlag, and moved it to BasicTypes.  That's why
      quite a few files are touched, but it's all routine.
      ae2c9b40
  9. 29 Oct, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15815 by parenthesizing the arguments to infix ~ · b8a797ec
      Ryan Scott authored
      An unfortunate consequence of commit
      b9483981 (`Remove HsEqTy and XEqTy`)
      is infix uses of `~` in TH quotes now desugar differently than
      before. In particular, we have that:
      
      ```haskell
      a ~ (Int -> Int)
      ```
      
      Now desugars to:
      
      ```haskell
      HsOpTy a (~) (HsOpTy Int (->) Int)
      ```
      
      Which GHC interprets as being:
      
      ```haskell
      a ~ Int -> Int
      ```
      
      Or, equivalently:
      
      ```haskell
      (a ~ Int) -> Int
      ```
      
      Which is different than what was intended! This is the cause
      of #15815.
      
      All of this has revealed that we likely need to renovate the way we
      desugar infix type operators to be more consistent with the treatment
      for infix expressions (see
      https://ghc.haskell.org/trac/ghc/ticket/15815#comment:5 for more on
      this.) Doing so would constitute a breaking change, however, so we
      will likely want to wait until another major GHC release to do this.
      
      In the meantime, this patch offers a non-invasive change to the way
      that infix uses of `~` are desugared. This makes the program
      in #15815 compile again by inserting extra `HsParTy`s around the
      arguments to `~` if they are lacking them.
      
      Test Plan: make test TEST=T15815
      
      Reviewers: int-index, goldfire, bgamari
      
      Reviewed By: int-index
      
      Subscribers: int-e, rwbarton, carter
      
      GHC Trac Issues: #15815
      
      Differential Revision: https://phabricator.haskell.org/D5274
      b8a797ec
  10. 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
  11. 17 Oct, 2018 1 commit
  12. 15 Oct, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15738 by defining (and using) parenthesizeHsContext · 02b2116e
      Ryan Scott authored
      With `QuantifiedConstraints`, `forall`s can appear in more
      nested positions than they could before, but `Convert` and the TH
      pretty-printer were failing to take this into account. On the
      `Convert` side, this is fixed by using a `parenthesizeHsContext`
      to parenthesize singleton quantified constraints that appear to the
      left of a `=>`. (A similar fix is applied to the TH pretty-printer.)
      
      Test Plan: make test TEST=T15738
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15738
      
      Differential Revision: https://phabricator.haskell.org/D5222
      02b2116e
  13. 14 Oct, 2018 1 commit
  14. 04 Oct, 2018 2 commits
    • Alec Theriault's avatar
      Don't drop arguments in TH type arguments · ba163c3b
      Alec Theriault authored
      Summary:
      When converting from TH AST back to HsType, we were occasionally
      dropping type arguments. This resulted in incorrectly accepted programs
      as well as incorrectly rejected programs.
      
      Test Plan: make TEST=T15360a && make TEST=T15360b
      
      Reviewers: goldfire, bgamari, tdammers
      
      Reviewed By: bgamari, tdammers
      
      Subscribers: RyanGlScott, rwbarton, carter
      
      GHC Trac Issues: #15360
      
      Differential Revision: https://phabricator.haskell.org/D5188
      ba163c3b
    • Alec Theriault's avatar
      Allow (unparenthesized) kind signatures · bace26aa
      Alec Theriault authored
      Summary: This allows for things like `[t :: MyKind]`, `(a :: k, b)`, and so on.
      
      Test Plan: make TEST=T11622 && make TEST=T8708
      
      Reviewers: RyanGlScott, bgamari, simonpj, goldfire, alanz
      
      Reviewed By: RyanGlScott, simonpj
      
      Subscribers: alanz, simonpj, rwbarton, mpickering, carter
      
      GHC Trac Issues: #11622, #8708
      
      Differential Revision: https://phabricator.haskell.org/D5173
      bace26aa
  15. 23 Sep, 2018 2 commits
  16. 14 Sep, 2018 1 commit
    • Michael Sloan's avatar
      Add support for ImplicitParams and RecursiveDo in TH · 9c6b7493
      Michael Sloan authored
      Summary:
      This adds TH support for the ImplicitParams and RecursiveDo extensions.
      
      I'm submitting this as one review because I cannot cleanly make
      the two commits independent.
      
      Initially, my goal was just to add ImplicitParams support, and
      I found that reasonably straightforward, so figured I might
      as well use my newfound knowledge to address some other TH omissions.
      
      Test Plan: Validate
      
      Reviewers: goldfire, austin, bgamari, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: carter, RyanGlScott, thomie
      
      GHC Trac Issues: #1262
      
      Differential Revision: https://phabricator.haskell.org/D1979
      9c6b7493
  17. 28 Aug, 2018 2 commits
    • Ryan Scott's avatar
      Rename kind vars in left-to-right order in bindHsQTyVars · 102284e7
      Ryan Scott authored
      Summary:
      When renaming kind variables in an `LHsQTyVars`, we were
      erroneously putting all of the kind variables in the binders
      //after// the kind variables in the body, resulting in #15568. The
      fix is simple: just swap the order of these two around.
      
      Test Plan: make test TEST=T15568
      
      Reviewers: simonpj, bgamari, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: goldfire, rwbarton, carter
      
      GHC Trac Issues: #15568
      
      Differential Revision: https://phabricator.haskell.org/D5108
      102284e7
    • Ryan Scott's avatar
      Fix #15572 by checking for promoted names in ConT · c46a5f20
      Ryan Scott authored
      Summary:
      When converting `ConT`s to `HsTyVar`s in `Convert`, we were
      failing to account for the possibility of promoted data constructor
      names appearing in a `ConT`, which could result in improper
      pretty-printing results (as observed in #15572). The fix is
      straightforward: use `Promoted` instead of `NotPromoted` when the
      name of a `ConT` is a data constructor name.
      
      Test Plan: make test TEST=T15572
      
      Reviewers: goldfire, bgamari, simonpj, monoidal
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: monoidal, rwbarton, carter
      
      GHC Trac Issues: #15572
      
      Differential Revision: https://phabricator.haskell.org/D5112
      c46a5f20
  18. 27 Aug, 2018 1 commit
  19. 21 Aug, 2018 3 commits
    • Andreas Klebinger's avatar
      Replace most occurences of foldl with foldl'. · 09c1d5af
      Andreas Klebinger authored
      This patch adds foldl' to GhcPrelude and changes must occurences
      of foldl to foldl'. This leads to better performance especially
      for quick builds where GHC does not perform strictness analysis.
      
      It does change strictness behaviour when we use foldl' to turn
      a argument list into function applications. But this is only a
      drawback if code looks ONLY at the last argument but not at the first.
      And as the benchmarks show leads to fewer allocations in practice
      at O2.
      
      Compiler performance for Nofib:
      
      O2 Allocations:
              -1 s.d.                -----            -0.0%
              +1 s.d.                -----            -0.0%
              Average                -----            -0.0%
      
      O2 Compile Time:
              -1 s.d.                -----            -2.8%
              +1 s.d.                -----            +1.3%
              Average                -----            -0.8%
      
      O0 Allocations:
              -1 s.d.                -----            -0.2%
              +1 s.d.                -----            -0.1%
              Average                -----            -0.2%
      
      Test Plan: ci
      
      Reviewers: goldfire, bgamari, simonmar, tdammers, monoidal
      
      Reviewed By: bgamari, monoidal
      
      Subscribers: tdammers, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4929
      09c1d5af
    • 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
  20. 16 Aug, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15527 by pretty-printing an RdrName prefixly · 5238f204
      Ryan Scott authored
      Summary:
      When `(.) @Int` is used without enabling `TypeApplications`,
      the resulting error message will pretty-print the (symbolic)
      `RdrName` `(.)`. However, it does so without parenthesizing it, which
      causes the pretty-printed expression to appear as `.@Int`. Yuck.
      
      Since the expression in a type application will always be prefix,
      we can fix this issue by using `pprPrefixOcc` instead of plain ol'
      `ppr`.
      
      Test Plan: make test TEST=T15527
      
      Reviewers: bgamari, monoidal, simonpj
      
      Reviewed By: monoidal, simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15527
      
      Differential Revision: https://phabricator.haskell.org/D5071
      5238f204
  21. 14 Aug, 2018 1 commit
    • Ryan Scott's avatar
      Properly designate LambdaCase alts as CaseAlt in TH · 32008a9d
      Ryan Scott authored
      Summary:
      When `\case` expressions are parsed normally, their
      alternatives are marked as `CaseAlt` (which means that they are
      pretty-printed without a `\` character in front of them, unlike for
      lambda expressions). However, `\case` expressions created by way of
      Template Haskell (in `Convert`) inconsistently designated the case
      alternatives as `LambdaExpr`, causing them to be pretty-printed
      poorly (as shown in #15518). The fix is simple: use `CaseAlt`
      consistently.
      
      Test Plan: make test TEST=T15518
      
      Reviewers: goldfire, bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15518
      
      Differential Revision: https://phabricator.haskell.org/D5069
      32008a9d
  22. 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
  23. 30 Jul, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15385 by using addDictsDs in matchGuards · 9d388eb8
      Ryan Scott authored
      Summary:
      When coverage checking pattern-matches, we rely on the call
      sites in the desugarer to populate the local dictionaries and term
      evidence in scope using `addDictsDs` and `addTmCsDs`. But it turns
      out that only the call site for desugaring `case` expressions was
      actually doing this properly. In another part of the desugarer,
      `matchGuards` (which handles pattern guards), it did not update the
      local dictionaries in scope at all, leading to #15385.
      
      Fixing this is relatively straightforward: just augment the
      `BindStmt` case of `matchGuards` to use `addDictsDs` and `addTmCsDs`.
      Accomplishing this took a little bit of import/export tweaking:
      
      * We now need to export `collectEvVarsPat` from `HsPat.hs`.
      * To avoid an import cycle with `Check.hs`, I moved `isTrueLHsExpr`
        from `DsGRHSs.hs` to `DsUtils.hs`, which resides lower on the
        import chain.
      
      Test Plan: make test TEST=T15385
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15385
      
      Differential Revision: https://phabricator.haskell.org/D4968
      9d388eb8
  24. 22 Jul, 2018 2 commits
  25. 20 Jul, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15423 by using pprAStmtContext · 99f45e2a
      Ryan Scott authored
      Summary:
      Previously, we were using `pprStmtContext` instead, which
      led to error messages missing indefinite articles where they were
      required.
      
      Test Plan: make test TEST="T13242a T7786 Typeable1"
      
      Reviewers: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15423
      
      Differential Revision: https://phabricator.haskell.org/D4992
      99f45e2a
  26. 15 Jul, 2018 1 commit
    • Alan Zimmerman's avatar
      TTG typo: XFieldOcc should be XCFieldOcc · 92695419
      Alan Zimmerman authored
      In the following
      
        data FieldOcc pass = FieldOcc { extFieldOcc     :: XFieldOcc pass
                                      , rdrNameFieldOcc :: Located RdrName
                                         -- ^ See Note [Located RdrNames] in HsExpr
                                      }
      
          | XFieldOcc
              (XXFieldOcc pass)
      
      we are using XFieldOcc for both the extFieldOcc type and the extra constructor.
      
      The first one should be XCFieldOcc
      
      Updates haddock submodule
      closes #15386
      92695419
  27. 13 Jul, 2018 2 commits
  28. 12 Jul, 2018 1 commit
  29. 10 Jul, 2018 2 commits
    • Richard Eisenberg's avatar
      Note [Ordering of implicit variables] · 7f4dd888
      Richard Eisenberg authored
      This addresses #14808
      
      [ci skip]
      7f4dd888
    • Simon Peyton Jones's avatar
      More refactoring in TcValidity · fd0f0334
      Simon Peyton Jones authored
      This patch responds to Trac #15334 by making it an error to
      write an instance declaration for a tuple constraint like
      (Eq [a], Show [a]).
      
      I then discovered that instance validity checking was
      scattered betweeen TcInstDcls and TcValidity, so I took
      the time to bring it all together, into
        TcValidity.checkValidInstHead
      
      In doing so I discovered that there are lot of special
      cases.   I have not changed them, but at least they are
      all laid out clearly now.
      fd0f0334
  30. 05 Jul, 2018 3 commits
    • Ryan Scott's avatar
      Fix #15331 with careful blasts of parenthesizeHsType · b6a33861
      Ryan Scott authored
      Summary:
      Another `-ddump-splices` bug that can be solved with more
      judicious use of parentheses.
      
      Test Plan: make test TEST=T15331
      
      Reviewers: goldfire, bgamari, alanz, tdammers
      
      Reviewed By: tdammers
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15331
      
      Differential Revision: https://phabricator.haskell.org/D4920
      b6a33861
    • Ryan Scott's avatar
      Parenthesize rank-n contexts in Convert · 57733978
      Ryan Scott authored
      Summary: A simple oversight.
      
      Test Plan: make test TEST=T15324
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15324
      
      Differential Revision: https://phabricator.haskell.org/D4910
      57733978
    • 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