1. 02 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14817 by not double-printing data family instance kind signatures · aef2b429
      Ryan Scott authored
      Within `pprDataFamInstDecl`, we were invoking `pprFamInstLHS` to
      pretty-print a data family instance header, and we were passing `Just` a
      kind signature to `pprFamInstLHS` to make it pretty-print the kind
      signature alongside it (this is a consequence of commit
      d1ef223c). But this is silly, because
      then invoke `pp_data_defn`, which //also// pretty-prints the kind
      signature, resulting in the kind signature being printed twice by
      mistake.
      
      This fix is simple—pass `Nothing` to `pprFamInstLHS` instead.
      
      Test Plan: make test TEST=T14817
      
      Reviewers: alanz, bgamari, mpickering
      
      Reviewed By: mpickering
      
      Subscribers: mpickering, rwbarton, thomie, carter
      
      GHC Trac Issues: #14817
      
      Differential Revision: https://phabricator.haskell.org/D4418
      aef2b429
  2. 18 Jan, 2018 2 commits
    • Ryan Scott's avatar
      Fix #14681 and #14682 with precision-aimed parentheses · 575c009d
      Ryan Scott authored
      It turns out that `Convert` was recklessly leaving off
      parentheses in two places:
      
      * Negative numeric literals
      * Patterns in lambda position
      
      This patch fixes it by adding three new functions, `isCompoundHsLit`,
      `isCompoundHsOverLit`, and `isCompoundPat`, and using them in the
      right places in `Convert`. While I was in town, I also sprinkled
      `isCompoundPat` among some `Pat`-constructing functions in `HsUtils`
      to help avoid the likelihood of this problem happening in other
      places. One of these places is in `TcGenDeriv`, and sprinkling
      `isCompountPat` there fixes #14682
      
      Test Plan: make test TEST="T14681 T14682"
      
      Reviewers: alanz, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14681, #14682
      
      Differential Revision: https://phabricator.haskell.org/D4323
      575c009d
    • Matthías Páll Gissurarson's avatar
      Inform hole substitutions of typeclass constraints (fixes #14273). · 1e14fd3e
      Matthías Páll Gissurarson authored
      This implements SPJ's suggestion on the ticket (#14273). We find the
      relevant constraints (ones that whose free unification variables are all
      mentioned in the type of the hole), and then clone the free unification
      variables of the hole and the relevant constraints. We then add a
      subsumption constraints and run the simplifier, and then check whether
      all the constraints were solved.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: RyanGlScott, rwbarton, thomie, carter
      
      GHC Trac Issues: #14273
      
      Differential Revision: https://phabricator.haskell.org/D4315
      1e14fd3e
  3. 15 Jan, 2018 1 commit
  4. 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
  5. 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
  6. 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
  7. 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
  8. 29 Jul, 2017 1 commit
  9. 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
  10. 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
  11. 11 Jul, 2017 1 commit
  12. 23 Jun, 2017 1 commit
  13. 21 Jun, 2017 1 commit
  14. 12 Jun, 2017 1 commit
  15. 11 May, 2017 1 commit
  16. 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
  17. 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
  18. 23 Apr, 2017 1 commit
  19. 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
  20. 06 Mar, 2017 1 commit
  21. 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
  22. 09 Feb, 2017 1 commit
  23. 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
  24. 26 Jan, 2017 1 commit
  25. 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
  26. 22 Jan, 2017 1 commit
  27. 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
  28. 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
  29. 17 Dec, 2016 2 commits
  30. 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
  31. 09 Dec, 2016 1 commit
  32. 24 Nov, 2016 1 commit
  33. 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
  34. 05 Nov, 2016 1 commit
  35. 03 Nov, 2016 1 commit
  36. 12 Oct, 2016 1 commit