1. 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
  2. 21 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14869 by being more mindful of Type vs. Constraint · 49ac3f0f
      Ryan Scott authored
      Summary:
      Before, we were using `isLiftedTypeKind` in `reifyType`
      before checking if a type was `Constraint`. But as it turns out,
      `isLiftedTypeKind` treats `Constraint` the same as `Type`, so every
      occurrence of `Constraint` would be reified as `Type`! To make things
      worse, the documentation for `isLiftedTypeKind` stated that it
      treats `Constraint` //differently// from `Type`, which simply isn't
      true.
      
      This revises the documentation for `isLiftedTypeKind` to reflect
      reality, and defers the `isLiftedTypeKind` check in `reifyType` so
      that it does not accidentally swallow `Constraint`.
      
      Test Plan: make test TEST=T14869
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14869
      
      Differential Revision: https://phabricator.haskell.org/D4474
      49ac3f0f
  3. 19 Mar, 2018 1 commit
    • Chaitanya Koparkar's avatar
      Turn a TH Name for built-in syntax into an unqualified RdrName · 9868f91f
      Chaitanya Koparkar authored
      Previously, the Renamer would turn any fully qualified Template Haskell
      name into a corresponding fully qualified `RdrName`. But this is not
      what we want for built-in syntax, as it produces unnecessarily qualified
      names (eg. GHC.Types.[], GHC.Tuple.(,) etc.).
      
      Test Plan: ./validate
      
      Reviewers: RyanGlScott, bgamari, goldfire
      
      Reviewed By: RyanGlScott, bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #13776
      
      Differential Revision: https://phabricator.haskell.org/D4506
      9868f91f
  4. 05 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14888 by adding more special cases for ArrowT · 6ee831f2
      Ryan Scott authored
      Summary:
      There were previously some situations where `(->)` would
      not be desugared or reified as `ArrowT`, leading to various oddities
      such as those observed in #14888. We now uniformly treat `(->)` as
      `ArrowT` in Template Haskell–world by checking for any tycon that
      has the same name as `(->)`, and converting that to `ArrowT`.
      
      Test Plan: make test TEST=T14888
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14888
      
      Differential Revision: https://phabricator.haskell.org/D4466
      6ee831f2
  5. 02 Mar, 2018 3 commits
    • Ryan Scott's avatar
      Fix #14838 by marking TH-spliced code as FromSource · ffb2738f
      Ryan Scott authored
      Previously, any Template Haskell code that was spliced would
      be marked as `Generated`, which would completely suppress pattern-
      match coverage warnings for it, which several folks found confusing.
      Indeed, Template Haskell-spliced code is "source" code in some sense,
      as users specifically request that it be put into their program, so
      changing its designation to `FromSource` makes sense from that
      perspective.
      
      Test Plan: make test TEST=T14838
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14838
      
      Differential Revision: https://phabricator.haskell.org/D4440
      ffb2738f
    • Ryan Scott's avatar
      Permit conversion of partially applied PromotedTupleTs · 68357020
      Ryan Scott authored
      Summary:
      We were simply missing a case in `Convert` for when have a
      `PromotedTupleT` that wasn't fully saturated. Easily fixed.
      
      Test Plan: make test TEST=T14843
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14843
      
      Differential Revision: https://phabricator.haskell.org/D4442
      68357020
    • 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
  6. 18 Feb, 2018 1 commit
    • Ryan Scott's avatar
      Rename the types in a GADT constructor in toposorted order · 043466b9
      Ryan Scott authored
      Previously, we were extracting the free variables from a
      GADT constructor in an incorrect order, which caused the type
      variables for the constructor's type signature to end up in
      non-toposorted order. Thankfully, rearranging the order of types
      during renaming makes swift work of this bug.
      
      This fixes a regression introduced in commit
      fa29df02.
      For whatever reason, that commit also commented out a
      significant portion of the `T13123` test. This code appears
      to work, so I've opted to uncomment it.
      
      Test Plan: make test TEST=T14808
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14808
      
      Differential Revision: https://phabricator.haskell.org/D4413
      043466b9
  7. 26 Jan, 2018 1 commit
    • Matthías Páll Gissurarson's avatar
      Sort valid substitutions for typed holes by "relevance" · cbdea959
      Matthías Páll Gissurarson authored
      This is an initial attempt at tackling the issue of how to order the
      suggestions provided by the valid substitutions checker, by sorting
      them by creating a graph of how they subsume each other. We'd like to
      order them in such a manner that the most "relevant" suggestions are
      displayed first, so that the suggestion that the user might be looking
      for is displayed before more far-fetched suggestions (and thus also
      displayed when they'd otherwise be cut-off by the
      `-fmax-valid-substitutions` limit). The previous ordering was based on
      the order in which the elements appear in the list of imports, which I
      believe is less correlated with relevance than this ordering.
      
      A drawback of this approach is that, since we now want to sort the
      elements, we can no longer "bail out early" when we've hit the
      `-fmax-valid-substitutions` limit.
      
      Reviewers: bgamari, dfeuer
      
      Reviewed By: dfeuer
      
      Subscribers: dfeuer, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4326
      cbdea959
  8. 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
  9. 15 Jan, 2018 1 commit
  10. 07 Dec, 2017 1 commit
    • Simon Peyton Jones's avatar
      Refactor ConDecl: Trac #14529 · fa29df02
      Simon Peyton Jones authored
      This patch refactors HsDecls.ConDecl.  Specifically
      
      * ConDeclGADT was horrible, with all the information hidden
        inside con_res_ty.  Now it's kept separate, as it should be.
      
      * ConDeclH98: use [LHsTyVarBndr] instead of LHsQTyVars for the
        existentials. There is no implicit binding here.
      
      * Add a field con_forall to both ConDeclGADT and ConDeclH98
        which says if there is an explicit user-written forall.
      
      * Field renamings in ConDecl
           con_cxt     to con_mb_cxt
           con_details to con_args
      
      There is an accompanying submodule update to Haddock.
      
      Also the following change turned out to remove a lot of clutter:
      
      * add a smart constructor for HsAppsTy, namely mkHsAppsTy,
        and use it consistently. This avoids a lot of painful pattern
        matching for the common singleton case.
      
      Two api-annotation tests (T10278, and T10399) are broken, hence marking
      them as expect_broken(14529).  Alan is going to fix them, probably by
      changing the con_forall field to
         con_forall :: Maybe SrcSpan
      instead of Bool
      fa29df02
  11. 30 Oct, 2017 1 commit
  12. 16 Oct, 2017 1 commit
  13. 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
  14. 25 Sep, 2017 1 commit
  15. 21 Sep, 2017 1 commit
    • Matthías Páll Gissurarson's avatar
      Also show types that subsume a hole as valid substitutions for that hole. · 1c920832
      Matthías Páll Gissurarson authored
      This builds on the previous "Valid substitutions include..." functionality,
      but add subsumption checking as well, so that the suggested valid substitutions
      show not only exact matches, but also identifiers that fit the hole by virtue of
      subsuming the type of the hole (i.e. being more general than the type of the
      hole).
      
      Building on the previous example, in the given program
      
      ```
      ps :: String -> IO ()
      ps = putStrLn
      
      ps2 :: a -> IO ()
      ps2 _ = putStrLn "hello, world"
      
      main :: IO ()
      main = _ "hello, world"
      ```
      
      The results would be something like
      
      ```
          • Found hole: _ :: [Char] -> IO ()
          • In the expression: _
            In the expression: _ "hello, world"
            In an equation for ‘main’: main = _ "hello, world"
          • Relevant bindings include main :: IO () (bound at t1.hs:8:1)
            Valid substitutions include
              ps :: String -> IO () (defined at t1.hs:2:1)
              ps2 :: forall a. a -> IO () (defined at t1.hs:5:1)
              putStrLn :: String -> IO ()
                (imported from ‘Prelude’ at t1.hs:1:1
                 (and originally defined in ‘System.IO’))
              fail :: forall (m :: * -> *). Monad m => forall a. String -> m a
                (imported from ‘Prelude’ at t1.hs:1:1
                 (and originally defined in ‘GHC.Base’))
              mempty :: forall a. Monoid a => a
                (imported from ‘Prelude’ at t1.hs:1:1
                 (and originally defined in ‘GHC.Base’))
              print :: forall a. Show a => a -> IO ()
                (imported from ‘Prelude’ at t1.hs:1:1
                 (and originally defined in ‘System.IO’))
              (Some substitutions suppressed;
               use -fmax-valid-substitutions=N or -fno-max-valid-substitutions)
      ```
      Signed-off-by: Matthías Páll Gissurarson's avatarMatthías Páll Gissurarson <mpg@mpg.is>
      
      Modified according to suggestions from Simon PJ
      
      Accept tests that match the expectations, still a few to look better at
      
      Swithced to using tcLookup, after sit down with SPJ at ICFP. Implications are WIP.
      
      Now works with polymorphism and constraints!
      
      We still need to merge the latest master, before we can make a patch.
      
      Wrap the type of the hole, instead of implication shenanigans,
      
      As per SPJs suggestion, this is simpler and feels closer to
      what we actually want to do.
      
      Updated tests with the new implementation
      
      Remove debugging trace and update documentation
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: RyanGlScott, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3930
      1c920832
  16. 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
  17. 12 Sep, 2017 1 commit
  18. 02 Sep, 2017 1 commit
    • Ryan Scott's avatar
      Fix #14167 by using isGadtSyntaxTyCon in more places · 8e4229ab
      Ryan Scott authored
      Summary:
      Two places in GHC effectively attempt to //guess// whether a data type
      was declared using GADT syntax:
      
      1. When reifying a data type in Template Haskell
      2. When pretty-printing a data type (e.g., via `:info` in GHCi)
      
      But there's no need for heuristics here, since we have a 100% accurate way to
      determine whether a data type was declared using GADT syntax: the
      `isGadtSyntaxTyCon` function! By simply using that as the metric, we obtain
      far more accurate TH reification and pretty-printing results.
      
      This is technically a breaking change, since Template Haskell reification will
      now reify some data type constructors as `(Rec)GadtC` that it didn't before,
      and some data type constructors that were previously reified as `(Rec)GadtC`
      will no longer be reified as such. But it's a very understandable breaking
      change, since the previous behavior was simply incorrect.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14167
      
      Differential Revision: https://phabricator.haskell.org/D3901
      8e4229ab
  19. 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
  20. 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
  21. 29 Jul, 2017 1 commit
  22. 28 Jul, 2017 3 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
    • Simon Peyton Jones's avatar
      Do not discard insolubles in implications · 452755de
      Simon Peyton Jones authored
      Trac #14000 showed up two errors
      
      * In TcRnTypes.dropInsolubles we dropped all implications, which
        might contain the very insolubles we wanted to keep.  This was
        an outright error, and is why the out-of-scope error was actually
        lost altogether in Trac #14000
      
      * In TcSimplify.simplifyInfer, if there are definite (insoluble)
        errors, it's better to suppress the following ambiguity test,
        because the type may be bogus anyway.  See TcSimplify
        Note [Quantification with errors].  This fix seems a bit clunky,
        but it'll do for now.
      452755de
  23. 27 Jul, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #13819 by refactoring TypeEqOrigin.uo_thing · c2417b87
      Richard Eisenberg authored
      The uo_thing field of TypeEqOrigin is used to track the
      "thing" (either term or type) that has the type (kind) stored
      in the TypeEqOrigin fields. Previously, this was sometimes a
      proper Core Type, which needed zonking and tidying. Now, it
      is only HsSyn: much simpler, and the error messages now use
      the user-written syntax.
      
      But this aspect of uo_thing didn't cause #13819; it was the
      sibling field uo_arity that did. uo_arity stored the number
      of arguments of uo_thing, useful when reporting something
      like "should have written 2 fewer arguments". We wouldn't want
      to say that if the thing didn't have two arguments. However,
      in practice, GHC was getting this wrong, and this message
      didn't seem all that helpful. Furthermore, the calculation
      of the number of arguments is what caused #13819 to fall over.
      This patch just removes uo_arity. In my opinion, the change
      to error messages is a nudge in the right direction.
      
      Test case: typecheck/should_fail/T13819
      c2417b87
  24. 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
  25. 11 Jul, 2017 3 commits
  26. 23 Jun, 2017 1 commit
  27. 21 Jun, 2017 1 commit
  28. 12 Jun, 2017 1 commit
  29. 20 May, 2017 1 commit
    • duog's avatar
      Compile modules that are needed by template haskell, even with -fno-code. · 53c78be0
      duog authored
      This patch relates to Trac #8025
      
      The goal here is to enable typechecking of packages that contain some
      template haskell. Prior to this patch, compilation of a package with
      -fno-code would fail if any functions in the package were called from
      within a splice.
      
      downsweep is changed to do an additional pass over the modules,
      targetting any ModSummaries transitively depended on by a module that
      has LangExt.TemplateHaskell enabled. Those targeted modules have
      hscTarget changed from HscNothing to the default target of the platform.
      
      There is a small change to the prevailing_target logic to enable this.
      
      A simple test is added.
      
      I have benchmarked with and without a patched haddock
      (available:https://github.com/duog/haddock/tree/wip-no-explicit-th-compi
      lation).  Running cabal haddock on the wreq package results in a 25%
      speedup on my machine:
      
      time output from patched cabal haddock:
      
      real    0m5.780s
      user    0m5.304s
      sys     0m0.496s
      time output from unpatched cabal haddock:
      
      real    0m7.712s
      user    0m6.888s
      sys     0m0.736s
      
      Reviewers: austin, bgamari, ezyang
      
      Reviewed By: bgamari
      
      Subscribers: bgamari, DanielG, rwbarton, thomie
      
      GHC Trac Issues: #8025
      
      Differential Revision: https://phabricator.haskell.org/D3441
      53c78be0
  30. 11 May, 2017 1 commit
  31. 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
  32. 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
  33. 23 Apr, 2017 1 commit