1. 06 Mar, 2017 1 commit
  2. 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
  3. 02 Mar, 2017 1 commit
  4. 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
  5. 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
  6. 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
  7. 22 Feb, 2017 2 commits
  8. 20 Feb, 2017 1 commit
  9. 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
  10. 10 Feb, 2017 3 commits
  11. 09 Feb, 2017 1 commit
  12. 07 Feb, 2017 1 commit
  13. 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
  14. 26 Jan, 2017 3 commits
    • Ryan Scott's avatar
      Don't unnecessarily qualify TH-converted instances with empty contexts · ad3d2dfa
      Ryan Scott authored
      Summary:
      The addition of rigorous pretty-printer tests
      (499e4382) had the unfortunate
      side-effect of revealing a bug in `hsSyn/Convert.hs` wherein instances are
      _always_ qualified with an instance context, even if the context is empty. This
      led to instances like this:
      
      ```
      instance Foo Int
      ```
      
      being pretty-printed like this!
      
      ```
      instance () => Foo Int
      ```
      
      We can prevent this by checking if the context is empty before adding an
      HsQualTy to the type.
      
      Also does some refactoring around HsForAllTys in `Convert` while I was in town.
      
      Fixes #13183.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, bgamari, austin, alanz
      
      Reviewed By: alanz
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3018
      
      GHC Trac Issues: #13183
      ad3d2dfa
    • Ryan Scott's avatar
      Add pragCompleteDName to templateHaskellNames · e4ab8ba7
      Ryan Scott authored
      95dc6dc0 forgot to add `pragCompleteDName`
      to the list of `templateHaskellNames`, which caused a panic if you actually
      tried to splice a `COMPLETE` pragma using Template Haskell. This applies the
      easy fix and augments the regression test to check for this in the future.
      e4ab8ba7
    • Matthew Pickering's avatar
      Template Haskell support for COMPLETE pragmas · 95dc6dc0
      Matthew Pickering authored
      Reviewers: RyanGlScott, austin, goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2997
      
      GHC Trac Issues: #13098
      95dc6dc0
  15. 24 Jan, 2017 2 commits
    • 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
    • niteria's avatar
      Skip path_with_commas when dyn unavailable · 90e83a7c
      niteria authored
      RyanGlScott reported a failure:
      ```
      Could not find module 'Prelude'; Perhaps you haven't
      installed the "dyn" libraries for package ‘base-4.10.0.0’?
      ```
      This might fix it.
      
      Test Plan: harbormaster
      
      Reviewers: austin, bgamari, thomie, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: thomie, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D3013
      90e83a7c
  16. 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
  17. 22 Jan, 2017 1 commit
  18. 21 Jan, 2017 1 commit
    • niteria's avatar
      Always use -Xlinker for -rpath · f9ccad23
      niteria authored
      Currently we use `-Wl` which takes a list of
      comma-separated options. Unfortunately that
      breaks when you use it with `-rpath` and
      a path that has commas in them.
      Buck, the build system, produces paths with
      commas in them.
      
      `-Xlinker` doesn't have this disadvantage
      and as far as I can tell is supported by
      both `gcc` and `clang`. Anecdotally `nvcc`
      supports `-Xlinker`, but not `-Wl`.
      
      Test Plan: ./validate, harbourmaster
      
      Reviewers: nomeata, simonmar, austin, bgamari, hvr
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2971
      f9ccad23
  19. 19 Jan, 2017 1 commit
    • Richard Eisenberg's avatar
      Update levity polymorphism · e7985ed2
      Richard Eisenberg authored
      This commit implements the proposal in
      https://github.com/ghc-proposals/ghc-proposals/pull/29 and
      https://github.com/ghc-proposals/ghc-proposals/pull/35.
      
      Here are some of the pieces of that proposal:
      
      * Some of RuntimeRep's constructors have been shortened.
      
      * TupleRep and SumRep are now parameterized over a list of RuntimeReps.
      * This
      means that two types with the same kind surely have the same
      representation.
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      false.
      
      * RepType.typePrimRep and friends now return a *list* of PrimReps. These
      functions can now work successfully on unboxed tuples. This change is
      necessary because we allow abstraction over unboxed tuple types and so
      cannot
      always handle unboxed tuples specially as we did before.
      
      * We sometimes have to create an Id from a PrimRep. I thus split PtrRep
      * into
      LiftedRep and UnliftedRep, so that the created Ids have the right
      strictness.
      
      * The RepType.RepType type was removed, as it didn't seem to help with
      * much.
      
      * The RepType.repType function is also removed, in favor of typePrimRep.
      
      * I have waffled a good deal on whether or not to keep VoidRep in
      TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
      represented in RuntimeRep, and typePrimRep will never return a list
      including
      VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
      imagine another design choice where we have a PrimRepV type that is
      PrimRep
      with an extra constructor. That seemed to be a heavier design, though,
      and I'm
      not sure what the benefit would be.
      
      * The last, unused vestiges of # (unliftedTypeKind) have been removed.
      
      * There were several pretty-printing bugs that this change exposed;
      * these are fixed.
      
      * We previously checked for levity polymorphism in the types of binders.
      * But we
      also must exclude levity polymorphism in function arguments. This is
      hard to check
      for, requiring a good deal of care in the desugarer. See Note [Levity
      polymorphism
      checking] in DsMonad.
      
      * In order to efficiently check for levity polymorphism in functions, it
      * was necessary
      to add a new bit of IdInfo. See Note [Levity info] in IdInfo.
      
      * It is now safe for unlifted types to be unsaturated in Core. Core Lint
      * is updated
      accordingly.
      
      * We can only know strictness after zonking, so several checks around
      * strictness
      in the type-checker (checkStrictBinds, the check for unlifted variables
      under a ~
      pattern) have been moved to the desugarer.
      
      * Along the way, I improved the treatment of unlifted vs. banged
      * bindings. See
      Note [Strict binds checks] in DsBinds and #13075.
      
      * Now that we print type-checked source, we must be careful to print
      * ConLikes correctly.
      This is facilitated by a new HsConLikeOut constructor to HsExpr.
      Particularly troublesome
      are unlifted pattern synonyms that get an extra void# argument.
      
      * Includes a submodule update for haddock, getting rid of #.
      
      * New testcases:
        typecheck/should_fail/StrictBinds
        typecheck/should_fail/T12973
        typecheck/should_run/StrictPats
        typecheck/should_run/T12809
        typecheck/should_fail/T13105
        patsyn/should_fail/UnliftedPSBind
        typecheck/should_fail/LevPolyBounded
        typecheck/should_compile/T12987
        typecheck/should_compile/T11736
      
      * Fixed tickets:
        #12809
        #12973
        #11736
        #13075
        #12987
      
      * This also adds a test case for #13105. This test case is
      * "compile_fail" and
      succeeds, because I want the testsuite to monitor the error message.
      When #13105 is fixed, the test case will compile cleanly.
      e7985ed2
  20. 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
  21. 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
  22. 17 Dec, 2016 2 commits
  23. 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
  24. 09 Dec, 2016 2 commits
    • Ryan Scott's avatar
      Rename TH constructors for deriving strategies · 5349d648
      Ryan Scott authored
      After talking to Richard, he and I concluded that choosing the rather
      common name `Newtype` to represent the corresponding deriving strategy
      in Template Haskell was a poor choice of name. I've opted to rename it
      to something less common (`NewtypeStrategy`) while we still have time. I
      also renamed the corrsponding datatype in the GHC internals so as to
      match it.
      
      Reviewers: austin, goldfire, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2814
      
      GHC Trac Issues: #10598
      5349d648
    • Ryan Scott's avatar
      Disambiguate reified closed type family kinds in TH · f65ff2c4
      Ryan Scott authored
      Summary:
      A continuation of #8953. This fixes an oversight in which the
      left-hand sides of closed type families, when reified in Template Haskell,
      would not be given kind annotations, even when they are necessary for
      disambiguation purposes in the presence of `PolyKinds`.
      
      Fixes #8953 and #12646.
      
      Test Plan: ./validate
      
      Reviewers: hvr, bgamari, austin, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2795
      
      GHC Trac Issues: #8953, #12646
      f65ff2c4
  25. 07 Dec, 2016 1 commit
    • Alan Zimmerman's avatar
      Add HsSyn prettyprinter tests · 499e4382
      Alan Zimmerman authored
      Summary:
      Add prettyprinter tests, which take a file, parse it, pretty print it,
      re-parse the pretty printed version and then compare the original and
      new ASTs (ignoring locations)
      
      Updates haddock submodule to match the AST changes.
      
      There are three issues outstanding
      
      1. Extra parens around a context are not reproduced. This will require an
         AST change and will be done in a separate patch.
      
      2. Currently if an `HsTickPragma` is found, this is not pretty-printed,
         to prevent noise in the output.
      
         I am not sure what the desired behaviour in this case is, so have left
         it as before. Test Ppr047 is marked as expected fail for this.
      
      3. Apart from in a context, the ParsedSource AST keeps all the parens from
         the original source.  Something is happening in the renamer to remove the
         parens around visible type application, causing T12530 to fail, as the
         dumped splice decl is after the renamer.
      
         This needs to be fixed by keeping the parens, but I do not know where they
         are being removed.  I have amended the test to pass, by removing the parens
         in the expected output.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, mpickering, simonpj, bgamari, austin
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: simonpj, goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2752
      
      GHC Trac Issues: #3384
      499e4382
  26. 24 Nov, 2016 1 commit
  27. 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
  28. 05 Nov, 2016 1 commit
  29. 03 Nov, 2016 1 commit