1. 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
  2. 19 Mar, 2018 1 commit
  3. 13 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Drop GHC 8.0 compatibility · 152055a1
      Ryan Scott authored
      GHC 8.4.1 is out, so now GHC's support window only extends
      back to GHC 8.2. This means we can delete gobs of code that were
      only used for GHC 8.0 support. Hooray!
      
      Test Plan: ./validate
      
      Reviewers: bgamari, erikd, dfeuer
      
      Reviewed By: bgamari, dfeuer
      
      Subscribers: alexbiehl, dfeuer, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4492
      152055a1
  4. 02 Mar, 2018 4 commits
    • Ryan Scott's avatar
      Fix #14838 by marking TH-spliced code as FromSource · ffb2738f
      Ryan Scott authored
      Previously, any Template Haskell code that was spliced would
      be marked as `Generated`, which would completely suppress pattern-
      match coverage warnings for it, which several folks found confusing.
      Indeed, Template Haskell-spliced code is "source" code in some sense,
      as users specifically request that it be put into their program, so
      changing its designation to `FromSource` makes sense from that
      perspective.
      
      Test Plan: make test TEST=T14838
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14838
      
      Differential Revision: https://phabricator.haskell.org/D4440
      ffb2738f
    • Ryan Scott's avatar
      Permit conversion of partially applied PromotedTupleTs · 68357020
      Ryan Scott authored
      Summary:
      We were simply missing a case in `Convert` for when have a
      `PromotedTupleT` that wasn't fully saturated. Easily fixed.
      
      Test Plan: make test TEST=T14843
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14843
      
      Differential Revision: https://phabricator.haskell.org/D4442
      68357020
    • Ryan Scott's avatar
      Fix #14817 by not double-printing data family instance kind signatures · aef2b429
      Ryan Scott authored
      Within `pprDataFamInstDecl`, we were invoking `pprFamInstLHS` to
      pretty-print a data family instance header, and we were passing `Just` a
      kind signature to `pprFamInstLHS` to make it pretty-print the kind
      signature alongside it (this is a consequence of commit
      d1ef223c). But this is silly, because
      then invoke `pp_data_defn`, which //also// pretty-prints the kind
      signature, resulting in the kind signature being printed twice by
      mistake.
      
      This fix is simple—pass `Nothing` to `pprFamInstLHS` instead.
      
      Test Plan: make test TEST=T14817
      
      Reviewers: alanz, bgamari, mpickering
      
      Reviewed By: mpickering
      
      Subscribers: mpickering, rwbarton, thomie, carter
      
      GHC Trac Issues: #14817
      
      Differential Revision: https://phabricator.haskell.org/D4418
      aef2b429
    • Tao He's avatar
      Improve exhaustive checking for guards in pattern bindings and MultiIf. · e8e9f6a7
      Tao He authored
      Previously we didn't do exhaustive checking on MultiIf expressions
      and guards in pattern bindings.
      
      We can construct the `LMatch` directly from GRHSs or [LHsExpr]
      (MultiIf's alts) then feed it to checkMatches, without construct the
      MatchGroup and using function `matchWrapper`.
      Signed-off-by: Tao He's avatarHE, Tao <sighingnow@gmail.com>
      
      Test Plan: make test TEST="T14773a T14773b"
      
      Reviewers: bgamari, RyanGlScott, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14773
      
      Differential Revision: https://phabricator.haskell.org/D4400
      e8e9f6a7
  5. 18 Jan, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14681 and #14682 with precision-aimed parentheses · 575c009d
      Ryan Scott authored
      It turns out that `Convert` was recklessly leaving off
      parentheses in two places:
      
      * Negative numeric literals
      * Patterns in lambda position
      
      This patch fixes it by adding three new functions, `isCompoundHsLit`,
      `isCompoundHsOverLit`, and `isCompoundPat`, and using them in the
      right places in `Convert`. While I was in town, I also sprinkled
      `isCompoundPat` among some `Pat`-constructing functions in `HsUtils`
      to help avoid the likelihood of this problem happening in other
      places. One of these places is in `TcGenDeriv`, and sprinkling
      `isCompountPat` there fixes #14682
      
      Test Plan: make test TEST="T14681 T14682"
      
      Reviewers: alanz, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14681, #14682
      
      Differential Revision: https://phabricator.haskell.org/D4323
      575c009d
  6. 15 Jan, 2018 1 commit
  7. 04 Jan, 2018 1 commit
    • Ryan Scott's avatar
      Make typeToLHsType produce kind signatures for tycon applications · 649e7772
      Ryan Scott authored
      Summary:
      `GeneralizedNewtypeDeriving` generates calls to `coerce`
      which take visible type arguments. These types must be produced by
      way of `typeToLHsType`, which converts a `Type` to an `LHsType`.
      However, `typeToLHsType` was leaving off important kind information
      when a `Type` contained a poly-kinded tycon application, leading to
      incorrectly generated code in #14579.
      
      This fixes the issue by tweaking `typeToLHsType` to generate
      explicit kind signatures for tycon applications. This makes the
      generated code noisier, but at least the program from #14579 now
      works correctly.
      
      Test Plan: make test TEST=T14579
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14579
      
      Differential Revision: https://phabricator.haskell.org/D4264
      649e7772
  8. 21 Dec, 2017 3 commits
    • Simon Peyton Jones's avatar
      Simplify HsPatSynDetails · 584cbd4a
      Simon Peyton Jones authored
      This is a pure refactoring.  Use HsConDetails to implement
      HsPatSynDetails, instead of defining a whole new data type.
      Less code, fewer types, all good.
      584cbd4a
    • Ryan Scott's avatar
      Improve treatment of sectioned holes · 4d41e921
      Ryan Scott authored
      Summary:
      Previously, GHC was pretty-printing left-section holes
      incorrectly and not parsing right-sectioned holes at all. This patch
      fixes both problems.
      
      Test Plan: make test TEST=T14590
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #14590
      
      Differential Revision: https://phabricator.haskell.org/D4273
      4d41e921
    • Ryan Scott's avatar
      Fix #14578 by checking isCompoundHsType in more places · 1bd91a7a
      Ryan Scott authored
      Summary:
      The `HsType` pretty-printer does not automatically insert
      parentheses where necessary for type applications, so a function
      `isCompoundHsType` was created in D4056 towards this purpose.
      However, it was not used in as many places as it ought to be,
      resulting in #14578.
      
      Test Plan: make test TEST=T14578
      
      Reviewers: alanz, bgamari, simonpj
      
      Reviewed By: alanz, simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14578
      
      Differential Revision: https://phabricator.haskell.org/D4266
      1bd91a7a
  9. 19 Dec, 2017 1 commit
  10. 18 Dec, 2017 1 commit
  11. 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
  12. 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
  13. 14 Nov, 2017 1 commit
  14. 11 Nov, 2017 1 commit
  15. 08 Nov, 2017 1 commit
  16. 07 Nov, 2017 2 commits
  17. 27 Oct, 2017 1 commit
    • Simon Marlow's avatar
      ApplicativeDo: handle BodyStmt (#12143) · 41f90559
      Simon Marlow authored
      Summary:
      It's simple to treat BodyStmt just like a BindStmt with a wildcard
      pattern, which is enough to fix #12143 without going all the way to
      using `<*` and `*>` (#10892).
      
      Test Plan:
      * new test cases in `ado004.hs`
      * validate
      
      Reviewers: niteria, simonpj, bgamari, austin, erikd
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #12143
      
      Differential Revision: https://phabricator.haskell.org/D4128
      41f90559
  18. 11 Oct, 2017 1 commit
  19. 07 Oct, 2017 2 commits
    • Ryan Scott's avatar
      Simply Data instance context for AmbiguousFieldOcc · f337a208
      Ryan Scott authored
      The current, verbose instance context can be compacted into
      `DataId pass`. Indeed, that's what most of the `Data` instances
      in this module already do, so this just makes things consistent.
      f337a208
    • Ryan Scott's avatar
      Fix #14320 by looking through HsParTy in more places · f1d2db68
      Ryan Scott authored
      Summary:
      GHC was needlessly rejecting GADT constructors' type
      signatures that were surrounded in parentheses due to the fact that
      `splitLHsForAllTy` and `splitLHsQualTy` (which are used to check as
      part of checking if GADT constructor return types are correct)
      weren't looking through parentheses (i.e., `HsParTy`). This is
      easily fixed, though.
      
      Test Plan: make test TEST=T14320
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14320
      
      Differential Revision: https://phabricator.haskell.org/D4072
      f1d2db68
  20. 05 Oct, 2017 1 commit
  21. 02 Oct, 2017 1 commit
  22. 26 Sep, 2017 1 commit
  23. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      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
  24. 15 Sep, 2017 1 commit
    • Ryan Scott's avatar
      Fix #14228 by marking SumPats as non-irrefutable · f4d50a0e
      Ryan Scott authored
      `isIrrefutableHsPat` should always return `False` for unboxed sum
      patterns (`SumPat`s), since they always have at least one other
      corresponding pattern of the same arity (since the minimum arity for a
      `SumPat` is 2). Failure to do so causes incorrect code to be generated
      for pattern synonyms that use unboxed sums, as shown in #14228.
      
      Test Plan: make test TEST=T14228
      
      Reviewers: austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #14228
      
      Differential Revision: https://phabricator.haskell.org/D3951
      f4d50a0e
  25. 12 Sep, 2017 1 commit
  26. 31 Aug, 2017 1 commit
    • Simon Peyton Jones's avatar
      Add debugPprType · 805b29bb
      Simon Peyton Jones authored
      We pretty-print a type by converting it to an IfaceType and
      pretty-printing that.  But
       (a) that's a bit indirect, and
       (b) delibrately loses information about (e.g.) the kind
            on the /occurrences/ of a type variable
      
      So this patch implements debugPprType, which pretty prints
      the type directly, with no fancy formatting.  It's just used
      for debugging.
      
      I took the opportunity to refactor the debug-pretty-printing
      machinery a little.  In particular, define these functions
      and use them:
      
        ifPprDeubug :: SDoc -> SDOc -> SDoc
          -- Says what to do with and without -dppr-debug
        whenPprDebug :: SDoc -> SDoc
          -- Says what to do with  -dppr-debug; without is empty
        getPprDebug :: (Bool -> SDoc) -> SDoc
      
      getPprDebug used to be called sdocPprDebugWith
      whenPprDebug used to be called ifPprDebug
      
      So a lot of files get touched in a very mechanical way
      805b29bb
  27. 29 Aug, 2017 4 commits
    • James Michael DuPont's avatar
      HsExpr: Fix typo · 15615254
      James Michael DuPont authored
      15615254
    • Ryan Scott's avatar
      Refactor type family instance abstract syntax declarations · 895a7650
      Ryan Scott authored
      This implements @simonpj's suggested refactoring of the abstract syntax
      for type/data family instances (from
      https://ghc.haskell.org/trac/ghc/ticket/14131#comment:9). This combines
      the previously separate `TyFamEqn` and `DataFamInstDecl` types into a
      single `FamEqn` datatype. This also factors the `HsImplicitBndrs` out of
      `HsTyPats` in favor of putting them just outside of `FamEqn` (as opposed
      to before, where all of the implicit binders were embedded inside of
      `TyFamEqn`/`DataFamInstDecl`). Finally, along the way I noticed that
      `dfid_fvs` and `tfid_fvs` were completely unused, so I removed them.
      
      Aside from some changes in parser test output, there is no change in
      behavior.
      
      Requires a Haddock submodule commit from my fork (at
      https://github.com/RyanGlScott/haddock/commit/815d2deb9c0222c916becccf84
      64b740c26255fd)
      
      Test Plan: ./validate
      
      Reviewers: simonpj, austin, goldfire, bgamari, alanz
      
      Reviewed By: bgamari
      
      Subscribers: mpickering, goldfire, rwbarton, thomie, simonpj
      
      GHC Trac Issues: #14131
      
      Differential Revision: https://phabricator.haskell.org/D3881
      895a7650
    • Simon Peyton Jones's avatar
      Comments only · 6e0e0b0e
      Simon Peyton Jones authored
      Better comment on con_qvars in ConDecl
      6e0e0b0e
    • David Feuer's avatar
      Make parsed AST dump output lazily · 29da01e0
      David Feuer authored
      Previously, `showAstData` produced a `String`. That `String` would
      then be converted to a `Doc` using `text` to implement
      `-ddump-parsed-ast`. But rendering `text` calculates the length
      of the `String` before doing anything else. Since the AST can be
      very large, this was bad: the whole dump string (potentially hundreds
      of millions of `Char`s) was accumulated in memory.
      
      Now, `showAstData` produces a `Doc` directly, which seems to work
      a lot better. As an extra bonus, the code is simpler and cleaner.
      The formatting has changed a bit, as the previous ad hoc approach
      didn't really match the pretty printer too well. If someone cares
      enough to request adjustments, we can surely make them.
      
      Reviewers: austin, bgamari, mpickering, alanz
      
      Reviewed By: bgamari
      
      Subscribers: mpickering, rwbarton, thomie
      
      GHC Trac Issues: #14161
      
      Differential Revision: https://phabricator.haskell.org/D3894
      29da01e0
  28. 25 Aug, 2017 1 commit
  29. 24 Aug, 2017 1 commit
  30. 22 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Revise function arity mismatch errors involving TypeApplications · 84760976
      Ryan Scott authored
      Summary:
      Currently, whenever you apply a function to too many arguments and
      some of those arguments happen to be visible type applications, the error
      message that GHC gives is rather confusing. Consider the message you receive
      when typechecking `id @Int 1 2`:
      
      ```
      The function `id` is applied to three arguments,
      but its type `Int -> Int` has only one
      ```
      
      This is baffling, since the two lines treat the visible type argument `@Int`
      differently. The top line ("applied to three arguments") includes `@Int`,
      whereas the bottom line ("has only one") excludes `@Int` from consideration.
      
      There are multiple ways one could fix this, which I explain in an addendum to
      `Note [Herald for matchExpectedFunTys]`. The approach adopted here is to change
      the herald of this error message to include visible type arguments, and to
      avoid counting them in the "applied to n arguments" part of the error. The end
      result is that the new error message for `id @Int 1 2` is now:
      
      ```
      The expression `id @Int` is applied to two arguments,
      but its type `Int -> Int` has only one
      ```
      
      Test Plan: make test TEST=T13902
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13902
      
      Differential Revision: https://phabricator.haskell.org/D3868
      84760976