1. 06 Jan, 2016 1 commit
  2. 31 Dec, 2015 2 commits
  3. 22 Dec, 2015 2 commits
    • Simon Peyton Jones's avatar
      Refactor named wildcards (again) · 575a98e4
      Simon Peyton Jones authored
      Michal's work on #10982, #11098, refactored the handling of named
      wildcards by making them more like ordinary type variables.
      
      This patch takes the same idea to its logical conclusion, resulting
      in a much tidier, tighter implementation.
      
      Read Note [The wildcard story for types] in HsTypes.
      
      Changes:
      
       * Named wildcards are ordinary type variables, throughout
      
       * HsType no longer has a data constructor for named wildcards
         (was NamedWildCard in HsWildCardInfo).  Named wildcards are
         simply HsTyVars
      
       * Similarly named wildcards disappear from Template Haskell
      
       * I refactored RnTypes to avoid polluting LocalRdrEnv with something
         as narrow as named wildcards.  Instead the named wildcard set is
         carried in RnTyKiEnv.
      
      There is a submodule update for Haddock.
      575a98e4
    • Ryan Scott's avatar
      Rework Template Haskell's handling of strictness · f975b0b1
      Ryan Scott authored
      Currently, Template Haskell's treatment of strictness is not enough to
      cover all possible combinations of unpackedness and strictness. In
      addition, it isn't equipped to deal with new features (such as
      `-XStrictData`) which can change a datatype's fields' strictness during
      compilation.
      
      To address this, I replaced TH's `Strict` datatype with
      `SourceUnpackedness` and `SourceStrictness` (which give the programmer a
      more complete toolkit to configure a datatype field's strictness than
      just `IsStrict`, `IsLazy`, and `Unpack`). I also added the ability to
      reify a constructor fields' strictness post-compilation through the
      `reifyConStrictness` function.
      
      Fixes #10697.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, bgamari, austin
      
      Reviewed By: goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1603
      
      GHC Trac Issues: #10697
      f975b0b1
  4. 21 Dec, 2015 1 commit
  5. 15 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Expose enabled language extensions to TH · c1e25536
      Ben Gamari authored
      This exposes `template-haskell` functions for querying the language
      extensions which are enabled when compiling a module,
      
      - an `isExtEnabled` function to check whether an extension is enabled
      - an `extsEnabled` function to obtain a full list of enabled extensions
      
      To avoid code duplication this adds a `GHC.LanguageExtensions` module to
      `ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
      consequence of this is that the ungainly `DynFlags` lost around 500
      lines. Moreover, flags corresponding to language extensions are now
      clearly distinguished from other flags due to the `LangExt.*` prefix.
      
      Updates haddock submodule.
      
      This fixes #10820.
      
      Test Plan: validate
      
      Reviewers: austin, spinda, hvr, goldfire, alanz
      
      Reviewed By: goldfire
      
      Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1200
      
      GHC Trac Issues: #10820
      c1e25536
  6. 14 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Use Cxt for deriving clauses in TH (#10819) · 04ab55d9
      Ben Gamari authored
      Summary:
      Deriving clauses in the TH representations of data, newtype, data
      instance, and newtype instance declarations previously were just [Name],
      which didn't allow for more complex derived classes, eg. multi-parameter
      typeclasses.
      
      This switches out [Name] for Cxt, representing the derived classes as
      types instead of names.
      
      Test Plan: validate
      
      Reviewers: goldfire, spinda, austin
      
      Reviewed By: goldfire, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1202
      
      GHC Trac Issues: #10819
      04ab55d9
  7. 12 Dec, 2015 1 commit
  8. 07 Dec, 2015 1 commit
  9. 18 Oct, 2015 2 commits
  10. 16 Oct, 2015 1 commit
  11. 13 Oct, 2015 1 commit
    • Ryan Scott's avatar
      Make dataToQa aware of Data instances which use functions to implement toConstr · d2f9972a
      Ryan Scott authored
      Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function
      freak out if using a `Data` instance that produces a `Constr` (by means of
      `toConstr`) using a function name instead of a data constructor name. While
      such `Data` instances are somewhat questionable, they are nevertheless present
      in popular libraries (e.g., `containers`), so we can at least make `dataToQa`
      aware of their existence.
      
      In order to properly distinguish strings which represent variables (as opposed
      to data constructors), it was necessary to move functionality from `Lexeme` (in
      `ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named
      `bin-package-db`).
      
      Reviewed By: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1313
      
      GHC Trac Issues: #10796
      d2f9972a
  12. 22 Sep, 2015 1 commit
  13. 17 Sep, 2015 1 commit
    • Ryan Scott's avatar
      Add namePackage function to template-haskell · 77662e13
      Ryan Scott authored
      Currently there exists a nameBase function (for retrieving a Name's OccName)
      and a nameModule function (for retrieving a Name's ModName), but there is no
      counterpart for PkgNames.
      
      This would be useful for implementing Template Haskell features which need
      to have easy access to a Name's package (e.g., automatically derived Lift
      instances).
      
      Reviewed By: goldfire, austin, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1237
      77662e13
  14. 03 Sep, 2015 1 commit
  15. 05 Aug, 2015 1 commit
    • Ryan Scott's avatar
      Add Fixity info for infix types · 575abf42
      Ryan Scott authored
      Template Haskell allows reification of fixity for infix functions and
      data constructors, and not for infix types. This adds a `Fixity` field
      to the relevant `Info` constructors that can have infix types (`ClassI`,
      `TyConI`, and `FamilyI`).
      
      I don't think that `VarI` or `PrimTyConI` can be infix, but I could be
      wrong.
      
      Test Plan: ./validate
      
      Reviewers: austin, goldfire, bgamari
      
      Reviewed By: goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1109
      
      GHC Trac Issues: #10704
      575abf42
  16. 03 Aug, 2015 1 commit
  17. 27 Jul, 2015 1 commit
    • spinda's avatar
      Add UInfixT to TH types (fixes #10522) · 21782739
      spinda authored
      UInfixT is like UInfixE or UInfixP but for types. Template Haskell
      splices can use it to punt fixity handling to GHC when constructing
      types.
      
      UInfixT is converted in compiler/hsSyn/Convert to a right-biased tree of
      HsOpTy, which is already rearranged in compiler/rename/RnTypes to match
      operator fixities.
      
      This patch consists of (1) adding UInfixT to the AST, (2) implementing
      the conversion and updating relevant comments, (3) updating
      pretty-printing and library support, and (4) adding tests.
      
      Test Plan: validate
      
      Reviewers: austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1088
      
      GHC Trac Issues: #10522
      21782739
  18. 21 Jul, 2015 1 commit
  19. 20 Jul, 2015 1 commit
    • thomasw's avatar
      Support wild cards in TH splices · 49373ffe
      thomasw authored
      - Declaration splices: partial type signatures are fully supported in TH
        declaration splices.
      
        For example, the wild cards in the example below will unify with `Eq
      a`
        and `a -> a -> Bool`, as expected:
      
      ```
      [d| foo :: _ => _
          foo x y = x == y |]
      ```
      
      - Expression splices: anonymous and named wild cards are supported in
        expression signatures, but extra-constraints wild cards aren't. Just
        as is the case for regular expression signatures.
      
      ```
      [e | Just True :: _a _ |]
      ```
      
      - Typed expression splices: the same wildcards as in (untyped)
        expression splices are supported.
      
      - Pattern splices: TH doesn't support type signatures in pattern
        splices, consequently, partial type signatures aren't supported
        either.
      
      - Type splices: partial type signatures are only partially supported in
        type splices, specifically: only anonymous wild cards are allowed.
      
        So `[t| _ |]`, `[t| _ -> Maybe _ |]` will work, but `[t| _ => _ |]` or
        `[| _a |]` won't (without `-XNamedWildCards`, the latter will work as
        the named wild card is treated as a type variable).
      
        Normally, named wild cards are collected before renaming a (partial)
        type signature. However, TH type splices are run during renaming, i.e.
        after the initial traversal, leading to out of scope errors for named
        wild cards. We can't just extend the initial traversal to collect the
        named wild cards in TH type splices, as we'd need to expand them,
        which is supposed to happen only once, during renaming.
      
        Similarly, the extra-constraints wild card is handled right before
        renaming too, and is therefore also not supported in a TH type splice.
        Another reason not to support extra-constraints wild cards in TH type
        splices is that a single signature can contain many TH type splices,
        whereas it mustn't contain more than one extra-constraints wild card.
        Enforcing would this be hard the way things are currently organised.
      
        Anonymous wild cards pose no problem, because they start without names
        and are given names during renaming. These names are collected right
        after renaming. The names generated for anonymous wild cards in TH
        type splices will thus be collected as well.
      
        With a more invasive refactoring of the renaming, partial type
        signatures could be fully supported in TH type splices. As only
        anonymous wild cards have been requested so far, these small changes
        satisfying this request will do for now. Also don't forget that a TH
        declaration splices support all kinds of wild cards.
      
      - Extra-constraints wild cards were silently ignored in expression and
        pattern signatures, appropriate error messages are now generated.
      
      Test Plan: run new tests
      
      Reviewers: austin, goldfire, adamgundry, bgamari
      
      Reviewed By: goldfire, adamgundry, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1048
      
      GHC Trac Issues: #10094, #10548
      49373ffe
  20. 16 Jul, 2015 1 commit
    • RyanGlScott's avatar
      Handle Char#, Addr# in TH quasiquoter (fixes #10620) · 2c9de9c9
      RyanGlScott authored
      DsMeta does not attempt to handle quasiquoted Char# or Addr# values,
      which causes expressions like `$([| 'a'# |])` or `$([| "abc"# |])` to
      fail
      with an `Exotic literal not (yet) handled by Template Haskell` error.
      
      To fix this, the API of `template-haskell` had to be changed so that
      `Lit`
      now has an extra constructor `CharPrimL` (a `StringPrimL` constructor
      already
      existed, but it wasn't used). In addition, `DsMeta` has to manipulate
      `CoreExpr`s directly that involve `Word8`s. In order to do this,
      `Word8` had
      to be added as a wired-in type to `TysWiredIn`.
      
      Actually converting from `HsCharPrim` and `HsStringPrim` to `CharPrimL`
      and
      `StringPrimL`, respectively, is pretty straightforward after that, since
      both `HsCharPrim` and `CharPrimL` use `Char` internally, and
      `HsStringPrim`
      uses a `ByteString` internally, which can easily be converted to
      `[Word8]`,
      which is what `StringPrimL` uses.
      
      Reviewers: goldfire, austin, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1054
      
      GHC Trac Issues: #10620
      2c9de9c9
  21. 03 Jun, 2015 1 commit
  22. 12 May, 2015 1 commit
  23. 11 May, 2015 1 commit
    • Edward Z. Yang's avatar
      Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382. · f16ddcee
      Edward Z. Yang authored
      
      
      Summary:
      This commit adds stage 1 support for Template Haskell
      quoting, e.g. [| ... expr ... |], which is useful
      for authors of quasiquoter libraries that do not actually
      need splices.  The TemplateHaskell extension now does not
      unconditionally fail; it only fails if the renamer encounters
      a splice that it can't run.
      
      In order to make sure the referenced data structures
      are consistent, template-haskell is now a boot library.
      There are some minor BC changes to template-haskell to make it boot
      on GHC 7.8.
      
      Note for reviewer: big diff changes are simply code
      being moved out of an ifdef; there was no other substantive
      change to that code.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, goldfire
      
      Subscribers: bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D876
      
      GHC Trac Issues: #10382
      f16ddcee
  24. 19 Dec, 2014 2 commits
  25. 10 Dec, 2014 2 commits
  26. 20 Nov, 2014 1 commit
  27. 19 Nov, 2014 2 commits
  28. 18 Nov, 2014 1 commit
  29. 12 Nov, 2014 4 commits
  30. 07 Oct, 2014 1 commit
    • glguy's avatar
      Add support for LINE pragma in template-haskell · adcb9dbc
      glguy authored
      Summary:
      Provide a way to generate {-# LINE #-} pragmas when generating
      Decs in Template Haskell. This allows more meaningful line
      numbers to be reported in compile-time errors for dynamically
      generated code.
      
      Test Plan: Run test suite
      
      Reviewers: austin, hvr
      
      Reviewed By: austin
      
      Subscribers: hvr, simonmar, ezyang, carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D299
      adcb9dbc
  31. 24 Sep, 2014 1 commit