1. 19 Apr, 2019 1 commit
    • Alec Theriault's avatar
      TH: make `Lift` and `TExp` levity-polymorphic · 57cf1133
      Alec Theriault authored
      Besides the obvious benefits of being able to manipulate `TExp`'s of
      unboxed types, this also simplified `-XDeriveLift` all while making
      it more capable.
      
        * `ghc-prim` is explicitly depended upon by `template-haskell`
      
        * The following TH things are parametrized over `RuntimeRep`:
      
            - `TExp(..)`
            - `unTypeQ`
            - `unsafeTExpCoerce`
            - `Lift(..)`
      
        * The following instances have been added to `Lift`:
      
            - `Int#`, `Word#`, `Float#`, `Double#`, `Char#`, `Addr#`
            - unboxed tuples of lifted types up to arity 7
            - unboxed sums of lifted types up to arity 7
      
          Ideally we would have levity-polymorphic _instances_ of unboxed
          tuples and sums.
      
        * The code generated by `-XDeriveLift` uses expression quotes
          instead of generating large amounts of TH code and having
          special hard-coded cases for some unboxed types.
      57cf1133
  2. 15 Mar, 2019 1 commit
  3. 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
  4. 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
  5. 14 Feb, 2019 1 commit
    • Alec Theriault's avatar
      Add `liftedTyped` to `Lift` class · 7f26b74e
      Alec Theriault authored
      Implements GHC proposal 43, adding a `liftTyped` method to the `Lift` typeclass.
      This also adds some documentation to `TExp`, describing typed splices and their
      advantages over their untyped counterparts.
      
      Resolves #14671.
      7f26b74e
  6. 21 Jan, 2019 1 commit
  7. 18 Jan, 2019 1 commit
  8. 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
  9. 30 Nov, 2018 1 commit
    • Alec Theriault's avatar
      Add 'Lift' instances for 'NonEmpty' and 'Void' · 47875bd4
      Alec Theriault authored
      Summary:
      Since 'NonEmpty' and 'Void' are now part of 'base', it makes
      sense that we put 'Lift' instances for them in 'template-haskell'.
      Not doing so is going to force users to define their own (possibly
      colliding) orphan instances downstream.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, bgamari, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: RyanGlScott, rwbarton, carter
      
      GHC Trac Issues: #15961
      
      Differential Revision: https://phabricator.haskell.org/D5391
      47875bd4
  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. 04 Oct, 2018 1 commit
  12. 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
  13. 27 Jul, 2018 1 commit
    • Michael Sloan's avatar
      Modifications to support loading GHC into GHCi · 60ecf43a
      Michael Sloan authored
      This change was previously part of
      [D4904](https://phabricator.haskell.org/D4904), but is being split off
      to aid in getting this reviewed and merged.
      
      * The compiler code is built with `NoImplicitPrelude`, but GHCi's
        modules are incompatible with it. So, this adds the pragma to all GHCi
        modules that didn't have it, and adds imports of Prelude.
      
      * In order to run GHC within itself, a `call of 'initGCStatistics`
        needed to be skipped. This uses CPP to skip it when
        `-DGHC_LOADED_INTO_GHCI` is set.
      
      * There is an environment variable workaround suggested by Ben Gamari
        [1], where `_GHC_TOP_DIR` can be used to specify GHC's top dir if `-B`
        isn't provided.  This can be used to solve a problem where the GHC being
        run within GHCi attempts to look in `inplace/lib/lib/` instead of
        `inplace/lib/`.
      
      [1]: https://phabricator.haskell.org/D4904#135438
      
      Reviewers: goldfire, bgamari, erikd, alpmestan
      
      Reviewed By: alpmestan
      
      Subscribers: alpmestan, lelf, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4986
      60ecf43a
  14. 12 Jul, 2018 1 commit
  15. 26 Jun, 2018 1 commit
  16. 20 Jun, 2018 1 commit
  17. 15 Jun, 2018 1 commit
    • Sylvain Henry's avatar
      Built-in Natural literals in Core · fe770c21
      Sylvain Henry authored
      Add support for built-in Natural literals in Core.
      
      - Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber
        constructor with a LitNumType field
      - Support built-in Natural literals
      - Add desugar warning for negative literals
      - Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency
        reasons
      
      This patch introduces only a few rules for Natural literals (compared
      to Integer's rules). Factorization of the built-in rules for numeric
      literals will be done in another patch as this one is already big to
      review.
      
      Test Plan:
        validate
        test build with integer-simple
      
      Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton,
      thomie
      
      GHC Trac Issues: #14170, #14465
      
      Differential Revision: https://phabricator.haskell.org/D4212
      fe770c21
  18. 05 Jun, 2018 1 commit
    • Ryan Scott's avatar
      Introduce DerivingVia · 8ed8b037
      Ryan Scott authored
      This implements the `DerivingVia` proposal put forth in
      https://github.com/ghc-proposals/ghc-proposals/pull/120.
      
      This introduces the `DerivingVia` deriving strategy. This is a
      generalization of `GeneralizedNewtypeDeriving` that permits the user
      to specify the type to `coerce` from.
      
      The major change in this patch is the introduction of the
      `ViaStrategy` constructor to `DerivStrategy`, which takes a type
      as a field. As a result, `DerivStrategy` is no longer a simple
      enumeration type, but rather something that must be renamed and
      typechecked. The process by which this is done is explained more
      thoroughly in section 3 of this paper
      ( https://www.kosmikus.org/DerivingVia/deriving-via-paper.pdf ),
      although I have inlined the relevant parts into Notes where possible.
      
      There are some knock-on changes as well. I took the opportunity to
      do some refactoring of code in `TcDeriv`, especially the
      `mkNewTypeEqn` function, since it was bundling all of the logic for
      (1) deriving instances for newtypes and
      (2) `GeneralizedNewtypeDeriving`
      into one huge broth. `DerivingVia` reuses much of part (2), so that
      was factored out as much as possible.
      
      Bumps the Haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari, goldfire, alanz
      
      Subscribers: alanz, goldfire, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #15178
      
      Differential Revision: https://phabricator.haskell.org/D4684
      8ed8b037
  19. 25 Mar, 2018 1 commit
    • 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
  20. 04 Dec, 2017 1 commit
  21. 30 Sep, 2017 1 commit
    • Ryan Scott's avatar
      Document a law for TH's Lift class · 626f0454
      Ryan Scott authored
      Inspired by the discussion in #14296, I've decided to
      document a law which is usually in the back of my mind when I'm using
      Template Haskell's `Lift` class, but isn't formally stated anywhere.
      That is, every `Lift` instance should satisfy (for all `x`):
      
      ```lang=haskell
      $(lift x) == x
      ```
      
      Test Plan: Read it
      
      Reviewers: austin, goldfire, bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D4050
      626f0454
  22. 22 Sep, 2017 1 commit
    • Facundo Domínguez's avatar
      Implement TH addCorePlugin. · 17558690
      Facundo Domínguez authored
      This allows template-haskell code to add plugins to the compilation
      pipeline. Otherwise, the user would have to pass -fplugin=... to ghc.
      
      For now, plugin modules in the current package can't be used. This is
      because when TH runs, it is too late to let GHC know that the plugin
      modules needed to be compiled first.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari, austin, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: angerman, rwbarton, mboes, thomie
      
      GHC Trac Issues: #13608
      
      Differential Revision: https://phabricator.haskell.org/D3821
      17558690
  23. 02 Sep, 2017 1 commit
    • Ryan Scott's avatar
      Document the intricacies of ForallC variable quantification better · 6330b0b0
      Ryan Scott authored
      Summary:
      I recently (re-)discovered that `ForallC` quantifies different type variables
      depending on whether `GadtC` is present or not. This is an important
      enough gotcha where I feel like this fact should also be advertised in the
      `template-haskell` documentation itself, so this patch does just that.
      
      Test Plan: Read it
      
      Reviewers: goldfire, austin, bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13885
      
      Differential Revision: https://phabricator.haskell.org/D3880
      6330b0b0
  24. 22 Aug, 2017 1 commit
  25. 05 Aug, 2017 1 commit
  26. 01 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Drop GHC 7.10 compatibility · c13720c8
      Ryan Scott authored
      GHC 8.2.1 is out, so now GHC's support window only extends back to GHC
      8.0. This means we can delete gobs of code that was only used for GHC
      7.10 support. Hooray!
      
      Test Plan: ./validate
      
      Reviewers: hvr, bgamari, austin, goldfire, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: Phyx, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3781
      c13720c8
  27. 11 Jul, 2017 1 commit
  28. 14 Jun, 2017 1 commit
  29. 27 May, 2017 1 commit
  30. 19 May, 2017 1 commit
  31. 09 Mar, 2017 2 commits
    • Gabor Greif's avatar
      Comments only [ci skip] · 9ff05742
      Gabor Greif authored
      9ff05742
    • bitonic's avatar
      Allow compilation of C/C++/ObjC/ObjC++ files with module from TH · 0fac488c
      bitonic authored
      The main goal is to easily allow the inline-c project (and
      similar projects such as inline-java) to emit C/C++ files to
      be compiled and linked with the current module.
      
      Moreover, `addCStub` is removed, since it's quite fragile. Most
      notably, the C stubs end up in the file generated by
      `CodeOutput.outputForeignStubs`, which is tuned towards
      generating a file for stubs coming from `capi` and Haskell-to-C
      exports.
      
      Reviewers: simonmar, austin, goldfire, facundominguez, dfeuer, bgamari
      
      Reviewed By: dfeuer, bgamari
      
      Subscribers: snowleopard, rwbarton, dfeuer, thomie, duncan, mboes
      
      Differential Revision: https://phabricator.haskell.org/D3280
      0fac488c
  32. 09 Feb, 2017 1 commit
  33. 02 Feb, 2017 1 commit
  34. 26 Jan, 2017 1 commit
  35. 07 Jan, 2017 1 commit
  36. 18 Dec, 2016 1 commit
    • Ryan Scott's avatar
      Introduce unboxedSum{Data,Type}Name to template-haskell · b5d788aa
      Ryan Scott authored
      Summary:
      In D2448 (which introduced Template Haskell support for unboxed
      sums), I neglected to add `unboxedSumDataName` and `unboxedSumTypeName`
      functions, since there wasn't any way you could write unboxed sum data or type
      constructors in prefix form to begin with (see #12514). But even if you can't
      write these `Name`s directly in source code, it would still be nice to be able
      to use these `Name`s in Template Haskell (for instance, to be able to treat
      unboxed sum type constructors like any other type constructors).
      
      Along the way, this uncovered a minor bug in `isBuiltInOcc_maybe` in
      `TysWiredIn`, which was calculating the arity of unboxed sum data constructors
      incorrectly.
      
      Test Plan: make test TEST=T12478_5
      
      Reviewers: osa1, goldfire, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2854
      
      GHC Trac Issues: #12478, #12514
      b5d788aa
  37. 15 Dec, 2016 1 commit
    • Ryan Scott's avatar
      Make unboxedTuple{Type,Data}Name support 0- and 1-tuples · 9550b8d8
      Ryan Scott authored
      Previously, these functions were hardcoded so as to always `error`
      whenever given an argument of 0 or 1. This restriction can be lifted
      pretty easily, however.
      
      This requires a slight tweak to `isBuiltInOcc_maybe` in `TysWiredIn` to
      allow it to recognize `Unit#` (which is the hard-wired `OccName` for
      unboxed 1-tuples).
      
      Fixes #12977.
      
      Test Plan: make test TEST=12977
      
      Reviewers: austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2847
      
      GHC Trac Issues: #12977
      9550b8d8
  38. 09 Dec, 2016 1 commit
    • Ryan Scott's avatar
      Rename TH constructors for deriving strategies · 5349d648
      Ryan Scott authored
      After talking to Richard, he and I concluded that choosing the rather
      common name `Newtype` to represent the corresponding deriving strategy
      in Template Haskell was a poor choice of name. I've opted to rename it
      to something less common (`NewtypeStrategy`) while we still have time. I
      also renamed the corrsponding datatype in the GHC internals so as to
      match it.
      
      Reviewers: austin, goldfire, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2814
      
      GHC Trac Issues: #10598
      5349d648
  39. 01 Oct, 2016 1 commit
    • Ryan Scott's avatar
      Implement deriving strategies · 9e862765
      Ryan Scott authored
      Allows users to explicitly request which approach to `deriving` to use
      via keywords, e.g.,
      
      ```
      newtype Foo = Foo Bar
        deriving Eq
        deriving stock    Ord
        deriving newtype Show
      ```
      
      Fixes #10598. Updates haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin,
      erikd, simonmar
      
      Reviewed By: alanz, bgamari, simonpj
      
      Subscribers: thomie, mpickering, oerjan
      
      Differential Revision: https://phabricator.haskell.org/D2280
      
      GHC Trac Issues: #10598
      9e862765