1. 15 Jan, 2018 1 commit
  2. 07 Oct, 2017 1 commit
    • Ryan Scott's avatar
      Incorporate changes from #11721 into Template Haskell · 341d3a78
      Ryan Scott authored
      Summary:
      #11721 changed the order of type variables in GADT
      constructor type signatures, but these changes weren't reflected in
      Template Haskell reification of GADTs. Let's do that.
      
      Along the way, I:
      
      * noticed that the `T13885` test was claiming to test TH reification
        of GADTs, but the reified data type wasn't actually a GADT! Since
        this patch touches that part of the codebase, I decided to fix
        this.
      * incorporated some feedback from @simonpj in
        https://phabricator.haskell.org/D3687#113566. (These changes alone
        don't account for any different in behavior.)
      
      Test Plan: make test TEST=T11721_TH
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: goldfire, bgamari, simonpj
      
      Subscribers: rwbarton, thomie, simonpj
      
      GHC Trac Issues: #11721
      
      Differential Revision: https://phabricator.haskell.org/D4070
      341d3a78
  3. 13 Sep, 2017 1 commit
    • Ryan Scott's avatar
      Check if -XStaticPointers is enabled when renaming static expressions · 9ff9c358
      Ryan Scott authored
      Summary:
      Trying to use `static` expressions without the `-XStaticPointers`
      extension enabled can lead to runtime errors. Normally, such a situation isn't
      possible, but Template Haskell provides a backdoor that allows it to happen,
      as shown in #14204.
      
      To prevent this, we ensure that `-XStaticPointers` is enabled when renaming
      `static` expressions.
      
      Test Plan: make test TEST=T14204
      
      Reviewers: facundominguez, austin, bgamari, simonpj
      
      Reviewed By: facundominguez, simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #14204
      
      Differential Revision: https://phabricator.haskell.org/D3931
      9ff9c358
  4. 22 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Fix #13885 by freshening reified GADT constructors' universal tyvars · 79b259ae
      Ryan Scott authored
      Summary:
      When reifying GADTs with Template Haskell, the universally quantified
      type variables were being reused across both the data type head and the
      constructors' type signatures. This had the annoying effect of causing sets
      of differently scoped variables to have the same uniques. To avoid this, we
      now freshen the universal tyvars before reifying the constructors so as to
      ensure they have distinct uniques.
      
      Test Plan: make test TEST=T13885
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13885
      
      Differential Revision: https://phabricator.haskell.org/D3867
      79b259ae
  5. 15 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Fix #14060 by more conservatively annotating TH-reified types · ad7b9452
      Ryan Scott authored
      Before, TH was quite generous in applying kind annotations to reified
      type constructors whose result kind happened to mention type variables.
      This could result in agonizingly large reified types, so this patch aims
      to quell this a bit by adopting a more nuanced algorithm for determining
      when a tycon application deserves a kind annotation.
      
      This implements the algorithm laid out in
      https://ghc.haskell.org/trac/ghc/ticket/14060#comment:1. I've updated
      `Note [Kind annotations on TyConApps]` to reflect the new wisdom.
      Essentially, instead of only checking if the result kind contains free
      variables, we also check if any of those variables do not appear free in
      injective positions in the argument kinds—only then do we put on a kind
      annotation.
      
      Bumps `haddock` submodule.
      
      Test Plan: make test TEST=T14060
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14060
      
      Differential Revision: https://phabricator.haskell.org/D3807
      ad7b9452
  6. 29 Jul, 2017 1 commit
  7. 28 Jul, 2017 2 commits
    • Ryan Scott's avatar
      Merge types and kinds in DsMeta · b3b564fb
      Ryan Scott authored
      Summary:
      Types and kinds are now the same in GHC... well, except in the code
      that involves Template Haskell, where types and kinds are given separate
      treatment. This aims to unify that treatment in the `DsMeta` module.
      
      The gist of this patch is replacing all uses of `repLKind` with `repLTy`.
      This is isn't quite as simple as one might imagine, since `repLTy` returns a
      `Core (Q Type)` (a monadic expression), whereas `repLKind` returns a
      `Core Kind` (a pure expression). This causes many awkward impedance mismatches.
      
      One option would be to change every combinator in `Language.Haskell.TH.Lib` to
      take `KindQ` as an argument instead of `Kind`. But this would be a breaking
      change of colossal proportions.
      
      Instead, this patch takes a somewhat different approach. This migrates the
      existing `Language.Haskell.TH.Lib` module to
      `Language.Haskell.TH.Lib.Internal`, and changes all `Kind`-related combinators
      in `Language.Haskell.TH.Lib.Internal` to live in `Q`. The new
      `Language.Haskell.TH.Lib` module then re-exports most of
      `Language.Haskell.TH.Lib.Internal` with the exception of the `Kind`-related
      combinators, for which it redefines them to be their current definitions (which
      don't live in `Q`). This allows us to retain backwards compatibility with
      previous `template-haskell` releases, but more importantly, it allows GHC to
      make as many changes to the `Internal` code as it wants for its purposes
      without fear of disrupting the public API.
      
      This solves half of #11785 (the other half being `TcSplice`).
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #11785
      
      Differential Revision: https://phabricator.haskell.org/D3751
      b3b564fb
    • Ryan Scott's avatar
      Error eagerly after renaming failures in reifyInstances · d6186496
      Ryan Scott authored
      Summary:
      Previously, if `reifyInstances` failed to discover a `Name` during
      renaming, it would blindy charge into typechecking, at which point GHC would
      become very confused at the absence of that `Name` and throw an internal error.
      A simple workaround is to fail eagerly after renaming errors.
      
      Test Plan: make test TEST=T13837
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #13837
      
      Differential Revision: https://phabricator.haskell.org/D3793
      d6186496
  8. 26 Jul, 2017 1 commit
    • Ryan Scott's avatar
      Fix #13968 by consulting isBuiltInOcc_maybe · d774b4e2
      Ryan Scott authored
      Summary:
      We were unconditionally reporting `Illegal binding of built-in syntax`
      in an error message, but this error doesn't make sense in certain Template
      Haskell scenarios which can trigger it. Let's give a more sensible error
      message by first checking if the name we're binding really is built-in syntax,
      using the handy `isBuiltInOcc_maybe` function.
      
      Test Plan: make test TEST=T13968
      
      Reviewers: bgamari, austin, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: goldfire, rwbarton, thomie
      
      GHC Trac Issues: #13968
      
      Differential Revision: https://phabricator.haskell.org/D3789
      d774b4e2
  9. 11 Jul, 2017 1 commit
  10. 23 Jun, 2017 1 commit
  11. 21 Jun, 2017 1 commit
  12. 12 Jun, 2017 1 commit
  13. 11 May, 2017 1 commit
  14. 04 May, 2017 1 commit
    • Simon Peyton Jones's avatar
      Deal with exceptions in dsWhenNoErrs · e7701976
      Simon Peyton Jones authored
      Gracious me.  Ever since this patch
      
        commit 37445780
        Author: Jan Stolarek <jan.stolarek@p.lodz.pl>
        Date:   Fri Jul 11 13:54:45 2014 +0200
      
            Injective type families
      
      TcRnMonad.askNoErrs has been wrong. It looked like this
      
         askNoErrs :: TcRn a -> TcRn (a, Bool)
         askNoErrs m
          = do { errs_var <- newTcRef emptyMessages
               ; res  <- setErrsVar errs_var m
               ; (warns, errs) <- readTcRef errs_var
               ; addMessages (warns, errs)
               ; return (res, isEmptyBag errs) }
      
      The trouble comes if 'm' throws an exception in the TcRn monad.
      Then 'errs_var is never read, so any errors are simply lost.
      
      This mistake was then propgated into DsMonad.dsWhenNoErrs, where
      it gave rise to Trac #13642.
      
      Thank to Ryan for narrowing it down so sharply.
      
      I did some refactoring, as usual.
      e7701976
  15. 28 Apr, 2017 1 commit
    • Ryan Scott's avatar
      Make the tyvars in TH-reified data family instances uniform · b2c38d6b
      Ryan Scott authored
      It turns out we were using two different sets of type variables when
      reifying data family instances in Template Haskell. We were using the
      tyvars quantifying over the instance itself for the LHS, but using the
      tyvars quantifying over the data family instance constructor for the
      RHS. This commit uses the instance tyvars for both the LHS and the RHS,
      fixing #13618.
      
      Test Plan: make test TEST=T13618
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: goldfire, bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13618
      
      Differential Revision: https://phabricator.haskell.org/D3505
      b2c38d6b
  16. 23 Apr, 2017 1 commit
  17. 09 Mar, 2017 1 commit
    • 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
  18. 06 Mar, 2017 1 commit
  19. 10 Feb, 2017 2 commits
    • Facundo Domínguez's avatar
      Relax test TH_addCStub2 so it succeeds on travis. · e79ef75d
      Facundo Domínguez authored
      Test Plan: ./validate
      
      Reviewers: bgamari, nomeata, austin, mpickering
      
      Reviewed By: mpickering
      
      Subscribers: mpickering, rwbarton, mboes, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3124
      e79ef75d
    • Ryan Scott's avatar
      Prevent Template Haskell splices from throwing a spurious TypeInType error · 283a3465
      Ryan Scott authored
      Summary:
      There was a rather annoying corner case where splicing poly-kinded
      Template Haskell declarations could trigger an error muttering about
      `TypeInType` not being enabled, whereas the equivalent non-TH code would
      compile without issue. This was causing by overzealous validity check in the
      renamer, wherein failed to distinguish between two different `Exact` names
      with the same `OccName`. As a result, it mistakenly believed some type
      variables were being used as both type and kind variables simultaneously! Ack.
      
      This avoids the issue by simply disabling the aforementioned validity check
      for Exact names. Fixes #12503.
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari, goldfire
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3022
      283a3465
  20. 09 Feb, 2017 1 commit
  21. 30 Jan, 2017 1 commit
    • Iavor S. Diatchki's avatar
      Fixes bug #11046 · 55935738
      Iavor S. Diatchki authored
      For some time now, type-level operators such as '+' have been treated as
      type constructors, rahter than type variables.  This pathc fixes TH's
      `lookupName` function to account for this behavior.
      
      Reviewers: bgamari, austin, goldfire, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: Phyx, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3025
      
      GHC Trac Issues: #11046
      55935738
  22. 26 Jan, 2017 1 commit
  23. 23 Jan, 2017 1 commit
    • Ryan Scott's avatar
      Don't quantify implicit type variables when quoting type signatures in TH · 729a5e45
      Ryan Scott authored
      Summary:
      A bug was introduced in GHC 8.0 in which Template Haskell-quoted type
      signatures would quantify _all_ their type variables, even the implicit ones.
      This would cause splices like this:
      
      ```
      $([d| idProxy :: forall proxy (a :: k). proxy a -> proxy a
            idProxy x = x
         |])
      ```
      
      To splice back in something that was slightly different:
      
      ```
      idProxy :: forall k proxy (a :: k). proxy a -> proxy a
      idProxy x = x
      ```
      
      Notice that the kind variable `k` is now explicitly quantified! What's worse,
      this now requires the `TypeInType` extension to be enabled.
      
      This changes the behavior of Template Haskell quoting to never explicitly
      quantify type variables which are implicitly quantified in the source.
      
      There are some other places where this behavior pops up too, including
      class methods, type ascriptions, `SPECIALIZE` pragmas, foreign imports,
      and pattern synonynms (#13018), so I fixed those too.
      
      Fixes #13018 and #13123.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Reviewed By: simonpj, goldfire
      
      Subscribers: simonpj, mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2974
      
      GHC Trac Issues: #13018, #13123
      729a5e45
  24. 22 Jan, 2017 1 commit
    • thomie's avatar
      Remove clean_cmd and extra_clean usage from .T files · 5d38fb69
      thomie authored
      The `clean_cmd` and `extra_clean` setup functions don't do anything.
      Remove them from .T files.
      
      Created using https://github.com/thomie/refactor-ghc-testsuite. This
      diff is a test for the .T-file parser/processor/pretty-printer in that
      repository.
      
          find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \;
      
      Tests containing inline comments or multiline strings are not modified.
      
      Preparation for #12223.
      
      Test Plan: Harbormaster
      
      Reviewers: austin, hvr, simonmar, mpickering, bgamari
      
      Reviewed By: mpickering
      
      Subscribers: mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3000
      
      GHC Trac Issues: #12223
      5d38fb69
  25. 27 Dec, 2016 1 commit
    • Peter Trommler's avatar
      Testsuite: Skip failing tests on PowerPC 64-bit · 4dec7d19
      Peter Trommler authored
      The Power ISA says the result of a division by zero is undefined.  So
      ignore stdout on PowerPC 64-bit systems.
      
      Disable ext-interp tests on 64-bit PowerPC.  We don't have support for
      PowerPC 64-bit ELF in the RTS linker, which is needed for the external
      interpreter.
      
      Test Plan: ./validate
      
      Reviewers: austin, simonmar, hvr, erikd, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2782
      4dec7d19
  26. 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
  27. 17 Dec, 2016 2 commits
  28. 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
  29. 09 Dec, 2016 1 commit
  30. 24 Nov, 2016 1 commit
  31. 17 Nov, 2016 1 commit
    • Facundo Domínguez's avatar
      Have reify work for local variables with functional dependencies. · 231a3ae1
      Facundo Domínguez authored
      It turned out that finalizers were run too early and information
      resulting from simplifying constraints was not available.
      
      This patch runs finalizers after a first call to simplifyTop, and
      then calls simplifyTop a second time to deal with constraints
      that could result from running the finalizers.
      
      Fixes T12777
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, bgamari, austin
      
      Reviewed By: simonpj
      
      Subscribers: mpickering, mboes, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2659
      
      GHC Trac Issues: #12777
      231a3ae1
  32. 05 Nov, 2016 1 commit
  33. 03 Nov, 2016 1 commit
  34. 12 Oct, 2016 1 commit
  35. 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
  36. 05 Sep, 2016 1 commit
    • Facundo Domínguez's avatar
      Don't ignore addTopDecls in module finalizers. · 71dd6e44
      Facundo Domínguez authored
      Summary:
      Module finalizer could call addTopDecls, however, the declarations
      added in this fashion were ignored. This patch makes sure to rename,
      type check and incorporate this declarations.
      
      Because a declaration may include a splice which calls addModFinalizer,
      the list of finalizers is repeteadly checked after adding declarations
      until no more finalizers remain.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, goldfire, simonpj, austin
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: simonmar, mboes, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2505
      
      GHC Trac Issues: #12559
      71dd6e44
  37. 29 Aug, 2016 1 commit