1. 28 Jul, 2017 2 commits
    • 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
  2. 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
  3. 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
  4. 11 Jul, 2017 3 commits
  5. 23 Jun, 2017 1 commit
  6. 21 Jun, 2017 1 commit
  7. 12 Jun, 2017 1 commit
  8. 20 May, 2017 1 commit
    • Douglas Wilson's avatar
      Compile modules that are needed by template haskell, even with -fno-code. · 53c78be0
      Douglas Wilson 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
  9. 11 May, 2017 1 commit
  10. 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
  11. 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
  12. 23 Apr, 2017 1 commit
  13. 14 Mar, 2017 1 commit
    • Ryan Scott's avatar
      Allow associated types to pattern-match in non-class-bound variables · 67345ccf
      Ryan Scott authored
      Summary:
      After 8136a5cb (#11450), if you have
      a class with an associated type:
      
      ```
      class C a where
        type T a b
      ```
      
      And you try to create an instance of `C` like this:
      
      ```
      instance C Int where
        type T Int Char = Bool
      ```
      
      Then it is rejected, since you're trying to instantiate the variable ``b`` with
      something other than a type variable. But this restriction proves quite
      onerous in practice, as it prevents you from doing things like this:
      
      ```
      class C a where
        type T a (b :: Identity c) :: c
      
      instance C Int where
        type T Int ('Identity x) = x
      ```
      
      You have to resort to an auxiliary type family in order to define this now,
      which becomes extremely tiring. This lifts this restriction and fixes #13398,
      in which it was discovered that adding this restriction broke code in the wild.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari, austin
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3302
      67345ccf
  14. 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
  15. 06 Mar, 2017 1 commit
  16. 03 Mar, 2017 2 commits
    • Ben Gamari's avatar
      Produce KindReps for common kinds in GHC.Types · c1dacb8a
      Ben Gamari authored
      Unfortunately this comes with a fair bit of implementation cost. Perhaps
      some refactoring would help, but in the interest of getting 8.2 out the
      door I'm pushing as-is.
      
      While this doesn't have nearly the effect on compiler allocations
      that D3166 has, it's still nothing to sneeze at. nofib shows,
      ```
      ------------------------------------------------------------------------
              Program               master           D3166            D3219
      ------------------------------------------------------------------------
              -1 s.d.                -----          -3.555%          -4.081%
              +1 s.d.                -----          +1.937%          +1.593%
              Average                -----          -0.847%          -1.285%
      ```
      
      Test Plan: Validate
      
      Reviewers: austin
      
      Subscribers: thomie, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D3219
      c1dacb8a
    • Ben Gamari's avatar
      TcTypeable: Try to reuse KindReps · a694cee7
      Ben Gamari authored
      Here we rework the TcTypeable implementation to reuse KindRep bindings
      when possible. This is an attempt at minimizing the impact of Typeable
      binding generation by reducing the number of bindings that we produce.
      
      It turns out that this produces some pretty reasonable compiler
      allocations improvements. It seems to erase most of the increases
      initially introduced by TTypeable in the testsuite. Moreover, nofib
      shows,
      ```
              -1 s.d.                -----          -3.555%
              +1 s.d.                -----          +1.937%
              Average                -----          -0.847%
      ```
      
      Here are a few of the high-scorers (ignore last column, which is for
      D3219),
      ```
      veritas
                Types             88800920         -18.945%         -21.480%
      
      veritas
              Tactics            540766744         -27.256%         -27.338%
      
      sched
                 Main            567013384          -4.947%          -5.358%
      
      listcompr
                 Main            532300000          -4.273%          -4.572%
      
      listcopy
                 Main            537785392          -4.382%          -4.635%
      
      anna
             BaseDefs           1984225032         -10.639%         -10.832%
      
      ```
      as expected, these tend to be modules with either very many or very
      large types.
      
      Test Plan: Validate
      
      Reviewers: austin, dfeuer
      
      Subscribers: simonmar, dfeuer, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3166
      a694cee7
  17. 02 Mar, 2017 1 commit
  18. 01 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Improve pretty-printing of types · 871b63e4
      Simon Peyton Jones authored
      When doing debug-printing it's really important that the free vars
      of a type are printed with their uniques.  The IfaceTcTyVar thing
      was a stab in that direction, but it only worked for TcTyVars, not
      TyVars.
      
      This patch does it properly, by keeping track of the free vars of the
      type when translating Type -> IfaceType, and passing that down through
      toIfaceTypeX.  Then when we find a variable, look in that set, and
      translate it to IfaceFreeTyVar if so.  (I renamed IfaceTcTyVar to
      IfaceFreeTyVar.)
      
      Fiddly but not difficult.
      
      Reviewers: austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3201
      871b63e4
  19. 28 Feb, 2017 2 commits
    • Simon Peyton Jones's avatar
      The Early Inline Patch · 2effe18a
      Simon Peyton Jones authored
      This very small patch switches on sm_inline even in the InitialPhase
      (aka "gentle" phase).   There is no reason not to... and the results
      are astonishing.
      
      I think the peformance of GHC itself improves by about 5%; and some
      programs get much smaller, quicker.  Result: across the board
      irmprovements in
      compile time performance.  Here are the changes in perf/compiler;
      the numbers are decreases in compiler bytes-allocated:
      
        3%   T5837
        7%   parsing001
        9%   T12234
        35%  T9020
        9%   T3064
        13%  T9961
        20%  T13056
        5%   T9872d
        5%   T9872c
        5%   T9872b
        7%   T9872a
        5%   T783
        35%  T12227
        20%  T1969
      
      Plus in perf/should_run
      
        5%   lazy-bs-alloc
      
      It wasn't as easy as it sounds: I did a raft of preparatory work in
      earlier patches.  But it's great!
      
      Reviewers: austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3203
      2effe18a
    • Ben Gamari's avatar
      Try submodule bumps again · 5fdb2b14
      Ben Gamari authored
      Bumps containers, time, and unix submodules.
      
      This reverts commit c347a121.
      5fdb2b14
  20. 26 Feb, 2017 1 commit
    • rwbarton's avatar
      tests: remove extra_files.py (#12223) · 3415bcaa
      rwbarton authored
      The script I used is included as testsuite/driver/kill_extra_files.py,
      though at this point it is for mostly historical interest.
      
      Some of the tests in libraries/hpc relied on extra_files.py, so this
      commit includes an update to that submodule.
      
      One test in libraries/process also relies on extra_files.py, but we
      cannot update that submodule so easily, so for now we special-case it
      in the test driver.
      3415bcaa
  21. 22 Feb, 2017 2 commits
  22. 20 Feb, 2017 1 commit
  23. 18 Feb, 2017 2 commits
    • Ben Gamari's avatar
      Disable Typeable binding generation for unboxed sums · 42ff5d97
      Ben Gamari authored
      These things are simply too expensive to generate at the moment. More
      work is needed here; see #13276 and #13261.
      42ff5d97
    • Ben Gamari's avatar
      Type-indexed Typeable · 8fa4bf9a
      Ben Gamari authored
      This at long last realizes the ideas for type-indexed Typeable discussed in A
      Reflection on Types (#11011). The general sketch of the project is described on
      the Wiki (Typeable/BenGamari). The general idea is that we are adding a type
      index to `TypeRep`,
      
          data TypeRep (a :: k)
      
      This index allows the typechecker to reason about the type represented by the `TypeRep`.
      This index representation mechanism is exposed as `Type.Reflection`, which also provides
      a number of patterns for inspecting `TypeRep`s,
      
      ```lang=haskell
      pattern TRFun :: forall k (fun :: k). ()
                    => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                              (arg :: TYPE r1) (res :: TYPE r2).
                       (k ~ Type, fun ~~ (arg -> res))
                    => TypeRep arg
                    -> TypeRep res
                    -> TypeRep fun
      
      pattern TRApp :: forall k2 (t :: k2). ()
                    => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b)
                    => TypeRep a -> TypeRep b -> TypeRep t
      
      -- | Pattern match on a type constructor.
      pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a
      
      -- | Pattern match on a type constructor including its instantiated kind
      -- variables.
      pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a
      ```
      
      In addition, we give the user access to the kind of a `TypeRep` (#10343),
      
          typeRepKind :: TypeRep (a :: k) -> TypeRep k
      
      Moreover, all of this plays nicely with 8.2's levity polymorphism, including the
      newly levity polymorphic (->) type constructor.
      
      Library changes
      ---------------
      
      The primary change here is the introduction of a Type.Reflection module to base.
      This module provides access to the new type-indexed TypeRep introduced in this
      patch. We also continue to provide the unindexed Data.Typeable interface, which
      is simply a type synonym for the existentially quantified SomeTypeRep,
      
          data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep
      
      Naturally, this change also touched Data.Dynamic, which can now export the
      Dynamic data constructor. Moreover, I removed a blanket reexport of
      Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable
      now).
      
      We also add a kind heterogeneous type equality type, (:~~:), to
      Data.Type.Equality.
      
      Implementation
      --------------
      
      The implementation strategy is described in Note [Grand plan for Typeable] in
      TcTypeable. None of it was difficult, but it did exercise a number of parts of
      the new levity polymorphism story which had not yet been exercised, which took
      some sorting out.
      
      The rough idea is that we augment the TyCon produced for each type constructor
      with information about the constructor's kind (which we call a KindRep). This
      allows us to reconstruct the monomorphic result kind of an particular
      instantiation of a type constructor given its kind arguments.
      
      Unfortunately all of this takes a fair amount of work to generate and send
      through the compilation pipeline. In particular, the KindReps can unfortunately
      get quite large. Moreover, the simplifier will float out various pieces of them,
      resulting in numerous top-level bindings. Consequently we mark the KindRep
      bindings as noinline, ensuring that the float-outs don't make it into the
      interface file. This is important since there is generally little benefit to
      inlining KindReps and they would otherwise strongly affect compiler performance.
      
      Performance
      -----------
      
      Initially I was hoping to also clear up the remaining holes in Typeable's
      coverage by adding support for both unboxed tuples (#12409) and unboxed sums
      (#13276). While the former was fairly straightforward, the latter ended up being
      quite difficult: while the implementation can support them easily, enabling this
      support causes thousands of Typeable bindings to be emitted to the GHC.Types as
      each arity-N sum tycon brings with it N promoted datacons, each of which has a
      KindRep whose size which itself scales with N. Doing this was simply too
      expensive to be practical; consequently I've disabled support for the time
      being.
      
      Even after disabling sums this change regresses compiler performance far more
      than I would like. In particular there are several testcases in the testsuite
      which consist mostly of types which regress by over 30% in compiler allocations.
      These include (considering the "bytes allocated" metric),
      
       * T1969:  +10%
       * T10858: +23%
       * T3294:  +19%
       * T5631:  +41%
       * T6048:  +23%
       * T9675:  +20%
       * T9872a: +5.2%
       * T9872d: +12%
       * T9233:  +10%
       * T10370: +34%
       * T12425: +30%
       * T12234: +16%
       * 13035:  +17%
       * T4029:  +6.1%
      
      I've spent quite some time chasing down the source of this regression and while
      I was able to make som improvements, I think this approach of generating
      Typeable bindings at time of type definition is doomed to give us unnecessarily
      large compile-time overhead.
      
      In the future I think we should consider moving some of all of the Typeable
      binding generation logic back to the solver (where it was prior to
      91c6b1f5). I've opened #13261 documenting this
      proposal.
      8fa4bf9a
  24. 10 Feb, 2017 3 commits
  25. 09 Feb, 2017 1 commit
  26. 07 Feb, 2017 1 commit
  27. 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
  28. 26 Jan, 2017 3 commits
  29. 24 Jan, 2017 1 commit
    • Ryan Scott's avatar
      Don't put foralls in front of TH-spliced GADT constructors that don't need them · 9fd87ef8
      Ryan Scott authored
      Summary:
      It turns out that D2974 broke this program
      (see https://phabricator.haskell.org/rGHC729a5e452db5#58801):
      
      ```lang=haskell
      {-# LANGUAGE ConstraintKinds #-}
      {-# LANGUAGE GADTs #-}
      {-# LANGUAGE KindSignatures #-}
      {-# LANGUAGE TemplateHaskell #-}
      {-# OPTIONS_GHC -ddump-splices #-}
      module Bug where
      
      import GHC.Exts (Constraint)
      
      $([d| data Dec13 :: (* -> Constraint) -> * where
              MkDec13 :: c a => a -> Dec13 c
          |])
      ```
      
      This was actually due to a long-standing bug in `hsSyn/Convert` that put
      unnecessary `forall`s in front of GADT constructors that didn't have any
      explicitly quantified type variables.
      
      This cargo-cults the code in `Convert` that handles `ForallT` and adapts
      it to `ForallC`. Fixes #13123 (for real this time).
      
      Test Plan: make test TEST=T13123
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3002
      
      GHC Trac Issues: #13123
      9fd87ef8