1. 27 Jan, 2020 1 commit
  2. 08 Jan, 2020 1 commit
  3. 30 Nov, 2019 1 commit
  4. 28 Nov, 2019 1 commit
  5. 27 Nov, 2019 1 commit
    • Sebastian Graf's avatar
      Make warnings for TH splices opt-in · 5a08f7d4
      Sebastian Graf authored
      In #17270 we have the pattern-match checker emit incorrect warnings. The
      reason for that behavior is ultimately an inconsistency in whether we
      treat TH splices as written by the user (`FromSource :: Origin`) or as
      generated code (`Generated`). This was first reported in #14838.
      
      The current solution is to TH splices as `Generated` by default and only
      treat them as `FromSource` when the user requests so
      (-fenable-th-splice-warnings). There are multiple reasons for opt-in
      rather than opt-out:
      
        * It's not clear that the user that compiles a splice is the author of the code
          that produces the warning. Think of the situation where she just splices in
          code from a third-party library that produces incomplete pattern matches.
          In this scenario, the user isn't even able to fix that warning.
        * Gathering information for producing the warnings (pattern-match check
          warnings in particular) is costly. There's no point in doing so if the user
          is not interested in those warnings.
      
      Fixes #17270, but not #14838, because the proper solution needs a GHC
      proposal extending the TH AST syntax.
      5a08f7d4
  6. 07 Nov, 2019 1 commit
    • Ryan Scott's avatar
      Clean up TH's treatment of unary tuples (or, #16881 part two) · 708c60aa
      Ryan Scott authored
      !1906 left some loose ends in regards to Template Haskell's treatment
      of unary tuples. This patch ends to tie up those loose ends:
      
      * In addition to having `TupleT 1` produce unary tuples, `TupE [exp]`
        and `TupP [pat]` also now produce unary tuples.
      * I have added various special cases in GHC's pretty-printers to
        ensure that explicit 1-tuples are printed using the `Unit` type.
        See `testsuite/tests/th/T17380`.
      * The GHC 8.10.1 release notes entry has been tidied up a little.
      
      Fixes #16881. Fixes #17371. Fixes #17380.
      708c60aa
  7. 01 Nov, 2019 1 commit
  8. 24 Oct, 2019 1 commit
  9. 13 Oct, 2019 1 commit
  10. 25 Sep, 2019 1 commit
    • Vladislav Zavialov's avatar
      Standalone kind signatures (#16794) · 0b5eede9
      Vladislav Zavialov authored
      Implements GHC Proposal #54: .../ghc-proposals/blob/master/proposals/0054-kind-signatures.rst
      
      With this patch, a type constructor can now be given an explicit
      standalone kind signature:
      
        {-# LANGUAGE StandaloneKindSignatures #-}
        type Functor :: (Type -> Type) -> Constraint
        class Functor f where
          fmap :: (a -> b) -> f a -> f b
      
      This is a replacement for CUSKs (complete user-specified
      kind signatures), which are now scheduled for deprecation.
      
      User-facing changes
      -------------------
      
      * A new extension flag has been added, -XStandaloneKindSignatures, which
        implies -XNoCUSKs.
      
      * There is a new syntactic construct, a standalone kind signature:
      
          type <name> :: <kind>
      
        Declarations of data types, classes, data families, type families, and
        type synonyms may be accompanied by a standalone kind signature.
      
      * A standalone kind signature enables polymorphic recursion in types,
        just like a function type signature enables polymorphic recursion in
        terms. This obviates the need for CUSKs.
      
      * TemplateHaskell AST has been extended with 'KiSigD' to represent
        standalone kind signatures.
      
      * GHCi :info command now prints the kind signature of type constructors:
      
          ghci> :info Functor
          type Functor :: (Type -> Type) -> Constraint
          ...
      
      Limitations
      -----------
      
      * 'forall'-bound type variables of a standalone kind signature do not
        scope over the declaration body, even if the -XScopedTypeVariables is
        enabled. See #16635 and #16734.
      
      * Wildcards are not allowed in standalone kind signatures, as partial
        signatures do not allow for polymorphic recursion.
      
      * Associated types may not be given an explicit standalone kind
        signature. Instead, they are assumed to have a CUSK if the parent class
        has a standalone kind signature and regardless of the -XCUSKs flag.
      
      * Standalone kind signatures do not support multiple names at the moment:
      
          type T1, T2 :: Type -> Type   -- rejected
          type T1 = Maybe
          type T2 = Either String
      
        See #16754.
      
      * Creative use of equality constraints in standalone kind signatures may
        lead to GHC panics:
      
          type C :: forall (a :: Type) -> a ~ Int => Constraint
          class C a where
            f :: C a => a -> Int
      
        See #16758.
      
      Implementation notes
      --------------------
      
      * The heart of this patch is the 'kcDeclHeader' function, which is used to
        kind-check a declaration header against its standalone kind signature.
        It does so in two rounds:
      
          1. check user-written binders
          2. instantiate invisible binders a la 'checkExpectedKind'
      
      * 'kcTyClGroup' now partitions declarations into declarations with a
        standalone kind signature or a CUSK (kinded_decls) and declarations
        without either (kindless_decls):
      
          * 'kinded_decls' are kind-checked with 'checkInitialKinds'
          * 'kindless_decls' are kind-checked with 'getInitialKinds'
      
      * DerivInfo has been extended with a new field:
      
          di_scoped_tvs :: ![(Name,TyVar)]
      
        These variables must be added to the context in case the deriving clause
        references tcTyConScopedTyVars. See #16731.
      0b5eede9
  11. 20 Sep, 2019 1 commit
  12. 09 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Use an empty data type in TTG extension constructors (#15247) · 6a03d77b
      Ryan Scott authored
      To avoid having to `panic` any time a TTG extension constructor is
      consumed, this MR introduces an uninhabited 'NoExtCon' type and uses
      that in every extension constructor's type family instance where it
      is appropriate. This also introduces a 'noExtCon' function which
      eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates
      a 'Void'.
      
      I also renamed the existing `NoExt` type to `NoExtField` to better
      distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of
      code churn resulting from this.
      
      Bumps the Haddock submodule. Fixes #15247.
      6a03d77b
  13. 05 Jul, 2019 1 commit
  14. 02 Jul, 2019 1 commit
  15. 12 Jun, 2019 1 commit
  16. 22 May, 2019 2 commits
    • Luite Stegeman's avatar
    • Ryan Scott's avatar
      Use HsTyPats in associated type family defaults · 6efe04de
      Ryan Scott authored
      Associated type family default declarations behave strangely in a
      couple of ways:
      
      1. If one tries to bind the type variables with an explicit `forall`,
         the `forall`'d part will simply be ignored. (#16110)
      2. One cannot use visible kind application syntax on the left-hand
         sides of associated default equations, unlike every other form
         of type family equation. (#16356)
      
      Both of these issues have a common solution. Instead of using
      `LHsQTyVars` to represent the left-hand side arguments of an
      associated default equation, we instead use `HsTyPats`, which is what
      other forms of type family equations use. In particular, here are
      some highlights of this patch:
      
      * `FamEqn` is no longer parameterized by a `pats` type variable, as
        the `feqn_pats` field is now always `HsTyPats`.
      * The new design for `FamEqn` in chronicled in
        `Note [Type family instance declarations in HsSyn]`.
      * `TyFamDefltEqn` now becomes the same thing as `TyFamInstEqn`. This
        means that many of `TyFamDefltEqn`'s code paths can now reuse the
        code paths for `TyFamInstEqn`, resulting in substantial
        simplifications to various parts of the code dealing with
        associated type family defaults.
      
      Fixes #16110 and #16356.
      6efe04de
  17. 21 May, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16666 by parenthesizing contexts in Convert · 4a6c8436
      Ryan Scott authored
      Most places where we convert contexts in `Convert` are actually in
      positions that are to the left of some `=>`, such as in superclasses
      and instance contexts. Accordingly, these contexts need to be
      parenthesized at `funPrec`. To accomplish this, this patch changes
      `cvtContext` to require a precedence argument for the purposes of
      calling `parenthesizeHsContext` and adjusts all `cvtContext` call
      sites accordingly.
      4a6c8436
  18. 15 Mar, 2019 1 commit
  19. 08 Mar, 2019 1 commit
    • Sylvain Henry's avatar
      TH: support raw bytes literals (#14741) · 224a6b86
      Sylvain Henry authored
      GHC represents String literals as ByteString internally for efficiency
      reasons. However, until now it wasn't possible to efficiently create
      large string literals with TH (e.g. to embed a file in a binary, cf #14741):
      TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack
      into a ByteString.
      
      This patch adds the possibility to efficiently create a "string" literal
      from raw bytes. We get the following compile times for different sizes
      of TH created literals:
      
      || Size || Before || After  || Gain ||
      || 30K  || 2.307s || 2.299  || 0%   ||
      || 3M   || 3.073s || 2.400s || 21%  ||
      || 30M  || 8.517s || 3.390s || 60%  ||
      
      Ticket #14741 can be fixed if the original code uses this new TH feature.
      224a6b86
  20. 01 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Visible dependent quantification · c26d299d
      Ryan Scott authored
      This implements GHC proposal 35
      (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst)
      by adding the ability to write kinds with
      visible dependent quantification (VDQ).
      
      Most of the work for supporting VDQ was actually done _before_ this
      patch. That is, GHC has been able to reason about kinds with VDQ for
      some time, but it lacked the ability to let programmers directly
      write these kinds in the source syntax. This patch is primarly about
      exposing this ability, by:
      
      * Changing `HsForAllTy` to add an additional field of type
        `ForallVisFlag` to distinguish between invisible `forall`s (i.e,
        with dots) and visible `forall`s (i.e., with arrows)
      * Changing `Parser.y` accordingly
      
      The rest of the patch mostly concerns adding validity checking to
      ensure that VDQ is never used in the type of a term (as permitting
      this would require full-spectrum dependent types). This is
      accomplished by:
      
      * Adding a `vdqAllowed` predicate to `TcValidity`.
      * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy`
        that only splits invisible `forall`s. This function is used in
        certain places (e.g., in instance declarations) to ensure that GHC
        doesn't try to split visible `forall`s (e.g., if it tried splitting
        `instance forall a -> Show (Blah a)`, then GHC would mistakenly
        allow that declaration!)
      
      This also updates Template Haskell by introducing a new `ForallVisT`
      constructor to `Type`.
      
      Fixes #16326. Also fixes #15658 by documenting this feature in the
      users' guide.
      c26d299d
  21. 08 Feb, 2019 1 commit
    • Alan Zimmerman's avatar
      API Annotations: AnnAt disconnected for TYPEAPP · cbfc9fca
      Alan Zimmerman authored
      For the code
      
          type family F1 (a :: k) (f :: k -> Type) :: Type where
            F1 @Peano a f = T @Peano f a
      
      the API annotation for the first @ is not attached to a SourceSpan in
      the ParsedSource
      
      Closes #16236
      cbfc9fca
  22. 28 Jan, 2019 1 commit
    • Ryan Scott's avatar
      Use sigPrec in more places in Convert and HsUtils · b1e569a5
      Ryan Scott authored
      Trac #16183 was caused by TH conversion (in `Convert`) not properly
      inserting parentheses around occurrences of explicit signatures where
      appropriate, such as in applications, function types, and type family
      equations. Solution: use `parenthesizeHsType sigPrec` in these
      places. While I was in town, I also updated `nlHsFunTy` to do the
      same thing.
      b1e569a5
  23. 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
  24. 24 Nov, 2018 1 commit
  25. 22 Nov, 2018 1 commit
    • David Eichmann's avatar
      Fix unused-import warnings · 6353efc7
      David Eichmann authored
      This patch fixes a fairly long-standing bug (dating back to 2015) in
      RdrName.bestImport, namely
      
         commit 9376249b
         Author: Simon Peyton Jones <simonpj@microsoft.com>
         Date:   Wed Oct 28 17:16:55 2015 +0000
      
         Fix unused-import stuff in a better way
      
      In that patch got the sense of the comparison back to front, and
      thereby failed to implement the unused-import rules described in
        Note [Choosing the best import declaration] in RdrName
      
      This led to Trac #13064 and #15393
      
      Fixing this bug revealed a bunch of unused imports in libraries;
      the ones in the GHC repo are part of this commit.
      
      The two important changes are
      
      * Fix the bug in bestImport
      
      * Modified the rules by adding (a) in
           Note [Choosing the best import declaration] in RdrName
        Reason: the previosu rules made Trac #5211 go bad again.  And
        the new rule (a) makes sense to me.
      
      In unravalling this I also ended up doing a few other things
      
      * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the
        things that are used, rather than [AvailInfo]. This is simpler
        and more direct.
      
      * Rename greParentName to greParent_maybe, to follow GHC
        naming conventions
      
      * Delete dead code RdrName.greUsedRdrName
      
      Bumps a few submodules.
      
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5312
      6353efc7
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. 28 Aug, 2018 1 commit
    • 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
  33. 27 Aug, 2018 1 commit
  34. 21 Aug, 2018 2 commits
    • Ben Gamari's avatar
      Fix redundant imports of Class · 966aa781
      Ben Gamari authored
      966aa781
    • Simon Peyton Jones's avatar
      Add a solveEqualities to tcClassDecl1 · 43b08cfb
      Simon Peyton Jones authored
      Trac #15505 showed that, when we have a type error, we
      could have an unfilled-in coercion hole.  We don't want an
      assertion error in that case.
      
      The underlying cause is that tcClassDecl1 should call
      solveEqualities to fully solve all top-level equalities
      (or fail in the attempt).
      
      I also refactored the ClassDecl case for tcTyClDecl1 into
      a new function tcClassDecl1.  That makes it symmetrical
      with the others.
      43b08cfb
  35. 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
  36. 12 Jul, 2018 1 commit
  37. 05 Jul, 2018 1 commit