1. 11 Jan, 2019 1 commit
  2. 06 Jan, 2019 1 commit
  3. 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
  4. 29 Dec, 2018 1 commit
  5. 24 Dec, 2018 1 commit
  6. 22 Dec, 2018 1 commit
  7. 11 Dec, 2018 1 commit
  8. 03 Dec, 2018 1 commit
    • Ryan Scott's avatar
      Fix embarrassing infinite loop in pprParendType · 89d80921
      Ryan Scott authored
      Summary:
      `pprParendType` was missing an explicit case for
      `EqualityT`, which caused it to fall through to a catch-all case
      that invokes `ppr`. But `ppr` itself does not have a case for a
      partial application of `EqualityT`, so //it// falls back to
      `pprParendType`, resulting in an infinite loop!
      
      The fix is simple: add a case for `EqualityT` in `pprParendType`.
      While I was in the neighborhood, I removed the catch-call case in
      `pprParendType` to make this sort of mistake less likely to happen
      in the future.
      
      Test Plan: make test TEST=T15985
      
      Reviewers: bgamari, monoidal, simonpj
      
      Reviewed By: monoidal, simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15985
      
      Differential Revision: https://phabricator.haskell.org/D5403
      89d80921
  9. 22 Nov, 2018 1 commit
  10. 08 Nov, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15845 by defining etaExpandFamInstLHS and using it · 63a81707
      Ryan Scott authored
      Summary:
      Both #9692 and #14179 were caused by GHC being careless
      about using eta-reduced data family instance axioms. Each of those
      tickets were fixed by manually whipping up some code to eta-expand
      the axioms. The same sort of issue has now caused #15845, so I
      figured it was high time to factor out the code that each of these
      fixes have in common.
      
      This patch introduces the `etaExpandFamInstLHS` function, which takes
      a family instance's type variables, LHS types, and RHS type, and
      returns type variables and LHS types that have been eta-expanded if
      necessary, in the case of a data family instance. (If it's a type
      family instance, `etaExpandFamInstLHS` just returns the supplied type
      variables and LHS types unchanged).
      
      Along the way, I noticed that many references to
      `Note [Eta reduction for data families]` (in `FamInstEnv`) had
      slightly bitrotted (they either referred to a somewhat different
      name, or claimed that the Note lived in a different module), so
      I took the liberty of cleaning those up.
      
      Test Plan: make test TEST="T9692 T15845"
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15845
      
      Differential Revision: https://phabricator.haskell.org/D5294
      63a81707
  11. 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
  12. 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
  13. 24 Oct, 2018 2 commits
    • Ryan Scott's avatar
      Fix #15792 by not reifying invisible arguments in AppTys · bfd93f90
      Ryan Scott authored
      Summary:
      The `reifyType` function in `TcSplice` is carefully designed
      to avoid reifying visible arguments to `TyConApp`s. However, the same
      care was not given towards the `AppTy` case, which lead to #15792.
      
      This patch changes to the `AppTy` case of `reifyType` so that it
      consults the kind of the function type to determine which of the
      argument types are invisible (and therefore should be dropped) during
      reification. This required crafting a variant of `tyConArgFlags`,
      which I dubbed `appTyArgFlags`, that accept an arbitrary function
      `Type` instead of a `TyCon`.
      
      Test Plan: make test TEST=T15792
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #15792
      
      Differential Revision: https://phabricator.haskell.org/D5252
      bfd93f90
    • Ryan Scott's avatar
      Keep top-level names in typed TH quotes alive · bb835c96
      Ryan Scott authored
      Summary:
      When renaming untyped TH quotes, some care is taken to
      ensure that uses of top-level names in quotes do not have their
      bindings discarded during desugaring. The same care was not applied
      to typed TH quotes, so this patch brings the two into sync.
      
      Test Plan: make test TEST=T15783
      
      Reviewers: bgamari, mpickering
      
      Reviewed By: mpickering
      
      Subscribers: mpickering, rwbarton, carter
      
      GHC Trac Issues: #15783
      
      Differential Revision: https://phabricator.haskell.org/D5248
      bb835c96
  14. 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
  15. 04 Oct, 2018 1 commit
    • 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
  16. 27 Sep, 2018 1 commit
    • Simon Marlow's avatar
      Fix for recover with -fexternal-interpreter (#15418) · d00c3086
      Simon Marlow authored
      Summary:
      When using -fexternal-interpreter, recover was not treating a Q
      compuation that simply registered an error with addErrTc as failing.
      
      Test Plan:
      New unit tests:
      * T15418 is the repro from in the ticket
      * TH_recover_warns is a new test to ensure that we're keeping warnings when
        the body of recover succeeds.
      
      Reviewers: bgamari, RyanGlScott, angerman, goldfire, erikd
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15418
      
      Differential Revision: https://phabricator.haskell.org/D5185
      d00c3086
  17. 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
  18. 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
  19. 27 Aug, 2018 2 commits
    • Ryan Scott's avatar
      Fix #15502 by not casting to Int during TH conversion · 7a3cda53
      Ryan Scott authored
      Summary:
      When turning an `IntegerL` to an `IntegralLit` during TH
      conversion, we were stupidly casting an `Integer` to an `Int` in
      order to determine how it should be pretty-printed. Unsurprisingly,
      this causes problems when the `Integer` doesn't lie within the bounds
      of an `Int`, as demonstrated in #15502.
      
      The fix is simple: don't cast to an `Int`.
      
      Test Plan: make test TEST=T15502
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #15502
      
      Differential Revision: https://phabricator.haskell.org/D5089
      7a3cda53
    • Ryan Scott's avatar
      Fix #15550 by quoting RULE names during TH conversion · 5e6cf2a9
      Ryan Scott authored
      Summary:
      When converting a `RuleP` to a GHC source `RuleD` during TH
      conversion, we were stupidly not double-quoting the name of the rule.
      Easily fixed.
      
      Test Plan: make test TEST=T15550
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #15550
      
      Differential Revision: https://phabricator.haskell.org/D5090
      5e6cf2a9
  20. 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
  21. 27 Jul, 2018 1 commit
  22. 22 Jul, 2018 1 commit
  23. 12 Jul, 2018 2 commits
  24. 06 Jul, 2018 1 commit
    • Michael Sloan's avatar
      Add a broken test for lingering state from TH unique names #9693 · fbe162f5
      Michael Sloan authored
      The stderr output is
      
      ```
      Loading with T9693_initial.hs
      
      T9693_main.hs:4:1:
          Same exact name in multiple name-spaces:
            type constructor or class ‘X’, declared at: T9693_main.hs:4:1
            data constructor ‘X’, declared at: T9693_main.hs:4:1
            Probable cause: you bound a unique Template Haskell name (NameU),
            perhaps via newName, in different name-spaces.
            If that's it, then -ddump-splices might be useful
      Reloading with T9693_modified.hs
      
      T9693_main.hs:1:1:
          Data constructor ‘X’ used as a type constructor
      ```
      
      The strange thing is that the modified version uses (mkName "X"), which should
      be fine for simultaneous use in both a data constructor and type constructor.
      Indeed, on a fresh load, the modified version works fine. So there is some sort
      of state left over from the prior load when (newName "X") was used.
      
      Test Plan: testsuite/tests/th/T9693.script
      
      Reviewers: bgamari, sighingnow, RyanGlScott
      
      Reviewed By: sighingnow, RyanGlScott
      
      Subscribers: RyanGlScott, sighingnow, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4926
      fbe162f5
  25. 05 Jul, 2018 2 commits
  26. 04 Jul, 2018 1 commit
  27. 10 Jun, 2018 1 commit
  28. 07 Jun, 2018 1 commit
  29. 30 May, 2018 1 commit
    • Matthías Páll Gissurarson's avatar
      Improved Valid Hole Fits · e0b44e2e
      Matthías Páll Gissurarson authored
      I've changed the name from `Valid substitutions` to `Valid hole fits`,
      since "substitution" already has a well defined meaning within the
      theory. As part of this change, the flags and output is reanamed, with
      substitution turning into hole-fit in most cases. "hole fit" was already
      used internally in the code, it's clear and shouldn't cause any
      confusion.
      
      In this update, I've also reworked how we manage side-effects in the
      hole we are considering.
      
      This allows us to consider local bindings such as where clauses and
      arguments to functions, suggesting e.g. `a` for `head (x:xs) where head
      :: [a] -> a`.
      
      It also allows us to find suggestions such as `maximum` for holes of
      type `Ord a => a -> [a]`, and `max` when looking for a match for the
      hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`.
      
      We also show much improved output for refinement hole fits, and
      fixes #14990. We now show the correct type of the function, but we also
      now show what the arguments to the function should be e.g. `foldl1 (_ ::
      Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`.
      
      I've moved the bulk of the code from `TcErrors.hs` to a new file,
      `TcHoleErrors.hs`, since it was getting too big to not live on it's own.
      
      This addresses the considerations raised in #14969, and takes proper
      care to set the `tcLevel` of the variables to the right level before
      passing it to the simplifier.
      
      We now also zonk the suggestions properly, which improves the output of
      the refinement hole fits considerably.
      
      This also filters out suggestions from the `GHC.Err` module, since even
      though `error` and `undefined` are indeed valid hole fits, they are
      "trivial", and almost never useful to the user.
      
      We now find the hole fits using the proper manner, namely by solving
      nested implications. This entails that the givens are passed along using
      the implications the hole was nested in, which in turn should mean that
      there will be fewer weird bugs in the typed holes.
      
      I've also added a new sorting method (as suggested by SPJ) and sort by
      the size of the types needed to turn the hole fits into the type of the
      hole. This gives a reasonable approximation to relevance, and is much
      faster than the subsumption check. I've also added a flag to toggle
      whether to use this new sorting algorithm (as is done by default) or the
      subsumption algorithm. This fixes #14969
      
      I've also added documentation for these new flags and update the
      documentation according to the new output.
      
      Reviewers: bgamari, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14969, #14990, #10946
      
      Differential Revision: https://phabricator.haskell.org/D4444
      e0b44e2e
  30. 24 May, 2018 1 commit
    • Ryan Scott's avatar
      Check for mismatched class methods during typechecking · 1879d9d2
      Ryan Scott authored
      Summary:
      Template Haskell provides a wormhole through which you can
      sneak methods that don't belong to a class into an instance for that
      class, bypassing the renamer's validity checks. The solution adopted
      here is to mirror the treatment for associated type family instances,
      which have an additional check in the typechecker which catch
      mismatched associated type families that were snuck through using
      Template Haskell. I've put a similar check for class methods into
      `tcMethods`.
      
      Test Plan: make test TEST=T12387
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #12387
      
      Differential Revision: https://phabricator.haskell.org/D4710
      1879d9d2
  31. 20 May, 2018 1 commit
  32. 14 May, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14875 by introducing PprPrec, and using it · 21e1a00c
      Ryan Scott authored
      Trying to determine when to insert parentheses during TH
      conversion is a bit of a mess. There is an assortment of functions
      that try to detect this, such as:
      
      * `hsExprNeedsParens`
      * `isCompoundHsType`
      * `hsPatNeedsParens`
      * `isCompoundPat`
      * etc.
      
      To make things worse, each of them have slightly different semantics.
      Plus, they don't work well in the presence of explicit type
      signatures, as #14875 demonstrates.
      
      All of these problems can be alleviated with the use of an explicit
      precedence argument (much like what `showsPrec` currently does). To
      accomplish this, I introduce a new `PprPrec` data type, and define
      standard predences for things like function application, infix
      operators, function arrows, and explicit type signatures (that last
      one is new). I then added `PprPrec` arguments to the various
      `-NeedsParens` functions, and use them to make smarter decisions
      about when things need to be parenthesized.
      
      A nice side effect is that functions like `isCompoundHsType` are
      now completely unneeded, since they're simply aliases for
      `hsTypeNeedsParens appPrec`. As a result, I did a bit of refactoring
      to remove these sorts of functions. I also did a pass over various
      utility functions in GHC for constructing AST forms and used more
      appropriate precedences where convenient.
      
      Along the way, I also ripped out the existing `TyPrec`
      data type (which was tailor-made for pretty-printing `Type`s) and
      replaced it with `PprPrec` for consistency.
      
      Test Plan: make test TEST=T14875
      
      Reviewers: alanz, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14875
      
      Differential Revision: https://phabricator.haskell.org/D4688
      21e1a00c
  33. 19 Apr, 2018 1 commit
  34. 10 Apr, 2018 1 commit
  35. 25 Mar, 2018 2 commits
    • Tao He's avatar
      Fix scoped type variables in TH for several constructs · a3986d7f
      Tao He authored
      Namely class methods, default signatures and pattern synonyms.
      
      When scoped type variables occur inside class default methods,
      default signatures and pattern synonyms, avoid re-create explicit
      type variables when represent the type signatures.
      
      This patch should fix Trac#14885.
      Signed-off-by: Tao He's avatarHE, Tao <sighingnow@gmail.com>
      
      Test Plan: make test TEST="T14885a T14885b T14885c"
      
      Reviewers: goldfire, bgamari, simonpj, RyanGlScott
      
      Reviewed By: simonpj, RyanGlScott
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14885
      
      Differential Revision: https://phabricator.haskell.org/D4469
      a3986d7f
    • Alec Theriault's avatar
      Support adding objects from TH · ceb91477
      Alec Theriault authored
      The user facing TH interface changes are:
      
        * 'addForeignFile' is renamed to 'addForeignSource'
        * 'qAddForeignFile'/'addForeignFile' now expect 'FilePath's
        * 'RawObject' is now a constructor for 'ForeignSrcLang'
        * 'qAddTempFile'/'addTempFile' let you request a temporary file
          from the compiler.
      
      Test Plan: unsure about this, added a TH test
      
      Reviewers: goldfire, bgamari, angerman
      
      Reviewed By: bgamari, angerman
      
      Subscribers: hsyl20, mboes, carter, simonmar, bitonic, ljli, rwbarton, thomie
      
      GHC Trac Issues: #14298
      
      Differential Revision: https://phabricator.haskell.org/D4217
      ceb91477