1. 12 Sep, 2017 1 commit
  2. 12 Aug, 2017 1 commit
  3. 27 Jul, 2017 1 commit
  4. 23 Jul, 2017 1 commit
  5. 26 May, 2017 1 commit
    • Simon Peyton Jones's avatar
      Some tidying up of type pretty-printing · ad14efd5
      Simon Peyton Jones authored
      Triggered by the changes in #13677, I ended up doing a bit of
      refactoring in type pretty-printing.
      * We were using TyOpPrec and FunPrec rather inconsitently, so
        I made it consisent.
      * That exposed the fact that we were a bit undecided about whether
        to print
           a + b -> c + d   vs   (a+b) -> (c+d)
        and similarly
           a ~ [b] => blah  vs   (a ~ [b]) => blah
        I decided to make TyOpPrec and FunPrec compare equal
        (in BasicTypes), so (->) is treated as equal precedence with
        other type operators, so you get the unambiguous forms above,
        even though they have more parens.
        We could readily reverse this decision.
        See Note [Type operator precedence] in BasicTypes
      * I fixed a bug in pretty-printing of HsType where some
        parens were omitted by mistake.
  6. 31 Mar, 2017 1 commit
    • Ben Gamari's avatar
      Clean up coreView/tcView. · 6575f4b6
      Ben Gamari authored
      In Core, Constraint should be considered fully equal to
      TYPE LiftedRep, in all ways. Accordingly, coreView should
      unwrap Constraint to become TYPE LiftedRep. Of course, this
      would be a disaster in the type checker.
      So, where previously we used coreView in both the type checker
      and in Core, we now have coreView and tcView, which differ only
      in their treatment of Constraint.
      Historical note: once upon a past, we had tcView distinct from
      coreView. Back then, it was because newtypes were unwrapped in
      Core but not in the type checker. The distinction is back, but
      for a different reason than before.
      This had a few knock-on effects:
       * The Typeable solver must explicitly handle Constraint to ensure
         that we produce the correct evidence.
       * TypeMap now respects the Constraint/Type distinction
      Finished by: bgamari
      Test Plan: ./validate
      Reviewers: simonpj, austin, bgamari
      Reviewed By: simonpj
      Subscribers: rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3316
  7. 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
    • 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
              -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
                Types             88800920         -18.945%         -21.480%
              Tactics            540766744         -27.256%         -27.338%
                 Main            567013384          -4.947%          -5.358%
                 Main            532300000          -4.273%          -4.572%
                 Main            537785392          -4.382%          -4.635%
             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
  8. 02 Mar, 2017 1 commit
  9. 27 Feb, 2017 1 commit
  10. 18 Feb, 2017 2 commits
    • 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,
      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
      We also add a kind heterogeneous type equality type, (:~~:), to
      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.
      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
      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
    • Edward Z. Yang's avatar
  11. 01 Feb, 2017 1 commit
  12. 22 Jan, 2017 1 commit
    • thomie's avatar
      Remove clean_cmd and extra_clean usage from .T files · 5d38fb69
      thomie authored
      The `clean_cmd` and `extra_clean` setup functions don't do anything.
      Remove them from .T files.
      Created using https://github.com/thomie/refactor-ghc-testsuite. This
      diff is a test for the .T-file parser/processor/pretty-printer in that
          find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \;
      Tests containing inline comments or multiline strings are not modified.
      Preparation for #12223.
      Test Plan: Harbormaster
      Reviewers: austin, hvr, simonmar, mpickering, bgamari
      Reviewed By: mpickering
      Subscribers: mpickering
      Differential Revision: https://phabricator.haskell.org/D3000
      GHC Trac Issues: #12223
  13. 20 Jan, 2017 1 commit
    • takano-akio's avatar
      Allow top-level string literals in Core (#8472) · d49b2bb2
      takano-akio authored
      This commits relaxes the invariants of the Core syntax so that a
      top-level variable can be bound to a primitive string literal of type
      This commit:
      * Relaxes the invatiants of the Core, and allows top-level bindings whose
        type is Addr# as long as their RHS is either a primitive string literal or
        another variable.
      * Allows the simplifier and the full-laziness transformer to float out
        primitive string literals to the top leve.
      * Introduces the new StgGenTopBinding type to accomodate top-level Addr#
      * Introduces a new type of labels in the object code, with the suffix "_bytes",
        for exported top-level Addr# bindings.
      * Makes some built-in rules more robust. This was necessary to keep them
        functional after the above changes.
      This is a continuation of D2554.
      Rebasing notes:
      This had two slightly suspicious performance regressions:
      * T12425: bytes allocated regressed by roughly 5%
      * T4029: bytes allocated regressed by a bit over 1%
      * T13035: bytes allocated regressed by a bit over 5%
      These deserve additional investigation.
      Rebased by: bgamari.
      Test Plan: ./validate --slow
      Reviewers: goldfire, trofi, simonmar, simonpj, austin, hvr, bgamari
      Reviewed By: trofi, simonpj, bgamari
      Subscribers: trofi, simonpj, gridaphobe, thomie
      Differential Revision: https://phabricator.haskell.org/D2605
      GHC Trac Issues: #8472
  14. 15 Dec, 2016 1 commit
  15. 07 Dec, 2016 1 commit
    • Alan Zimmerman's avatar
      Add HsSyn prettyprinter tests · 499e4382
      Alan Zimmerman authored
      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
  16. 13 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Kill Type pretty-printer · 6c0f10fa
      Ben Gamari authored
      Here we consolidate the pretty-printing logic for types in IfaceType. We
      need IfaceType regardless and the printer for Type can be implemented in
      terms of that for IfaceType. See #11660.
      Note that this is very much a work-in-progress. Namely I still have yet
      to ponder how to ease the hs-boot file situation, still need to rip out
      more dead code, need to move some of the special cases for, e.g., `*` to
      the IfaceType printer, and need to get it to validate. That being said,
      it comes close to validating as-is.
      Test Plan: Validate
      Reviewers: goldfire, austin
      Subscribers: goldfire, thomie, simonpj
      Differential Revision: https://phabricator.haskell.org/D2528
      GHC Trac Issues: #11660
  17. 21 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      A collection of type-inference refactorings. · 3f5673f3
      Simon Peyton Jones authored
      This patch does a raft of useful tidy-ups in the type checker.
      I've been meaning to do this for some time, and finally made
      time to do it en route to ICFP.
      1. Modify TcType.ExpType to make a distinct data type,
         InferResult for the Infer case, and consequential
      2. Define a new function TcUnify.fillInferResult, to fill in
         an InferResult. It uses TcMType.promoteTcType to promote
         the type to the level of the InferResult.
         See TcMType Note [Promoting a type]
         This refactoring is in preparation for an improvement
         to typechecking pattern bindings, coming next.
         I flirted with an elaborate scheme to give better
         higher rank inference, but it was just too complicated.
         See TcMType Note [Promotion and higher rank types]
      3. Add to InferResult a new field ir_inst :: Bool to say
         whether or not the type used to fill in the
         InferResult should be deeply instantiated.  See
         TcUnify Note [Deep instantiation of InferResult].
      4. Add a TcLevel to SkolemTvs. This will be useful generally
          - it's a fast way to see if the type
            variable escapes when floating (not used yet)
          - it provides a good consistency check when updating a
            unification variable (TcMType.writeMetaTyVarRef, the
            level_check_ok check)
         I originally had another reason (related to the flirting
         in (2), but I left it in because it seems like a step in
         the right direction.
      5. Reduce and simplify the plethora of uExpType,
         tcSubType and related functions in TcUnify.  It was
         such an opaque mess and it's still not great, but it's
      6. Simplify the uo_expected field of TypeEqOrigin.  Richard
         had generatlised it to a ExpType, but it was almost always
         a Check type.  Now it's back to being a plain TcType which
         is much, much easier.
      7. Improve error messages by refraining from skolemisation when
         it's clear that there's an error: see
         TcUnify Note [Don't skolemise unnecessarily]
      8. Type.isPiTy and isForAllTy seem to be missing a coreView check,
         so I added it
      9. Kill off tcs_used_tcvs.  Its purpose is to track the
         givens used by wanted constraints.  For dictionaries etc
         we do that via the free vars of the /bindings/ in the
         implication constraint ic_binds.  But for coercions we
         just do update-in-place in the type, rather than
         generating a binding.  So we need something analogous to
         bindings, to track what coercions we have added.
         That was the purpose of tcs_used_tcvs.  But it only
         worked for a /single/ iteration, whereas we may have
         multiple iterations of solving an implication.  Look
         at (the old) 'setImplicationStatus'.  If the constraint
         is unsolved, it just drops the used_tvs on the floor.
         If it becomes solved next time round, we'll pick up
         coercions used in that round, but ignore ones used in
         the first round.
         There was an outright bug.  Result = (potentialy) bogus
         unused-constraint errors.  Constructing a case where this
         actually happens seems quite trick so I did not do so.
         Solution: expand EvBindsVar to include the (free vars of
         the) coercions, so that the coercions are tracked in
         essentially the same way as the bindings.
         This turned out to be much simpler.  Less code, more
      10. Make the ic_binds field in an implication have type
            ic_binds :: EvBindsVar
          instead of (as previously)
             ic_binds :: Maybe EvBindsVar
          This is notably simpler, and faster to use -- less
          testing of the Maybe.  But in the occaional situation
          where we don't have anywhere to put the bindings, the
          belt-and-braces error check is lost.  So I put it back
          as an ASSERT in 'setImplicationStatus' (see the use of
      All these changes led to quite bit of error message wibbling
  18. 26 Apr, 2016 1 commit
  19. 20 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      SCC analysis for instances as well as types/classes · 353d8ae6
      Simon Peyton Jones authored
      This big patch is in pursuit of Trac #11348.
      It is largely the work of Alex Veith (thank you!), with some
      follow-up simplification and refactoring from Simon PJ.
      The main payload is described in RnSource
        Note [Dependency analysis of type, class, and instance decls]
      which is pretty detailed.
      * There is a new data type HsDecls.TyClGroup, for a strongly
        connected component of type/class/instance/role decls.
        The hs_instds field of HsGroup disappears, in consequence
        This forces some knock-on changes, including a minor
        haddock submodule update
      Smaller, weakly-related things
      * I found that both the renamer and typechecker were building an
        identical env for RoleAnnots, so I put common code for
        RoleAnnotEnv in RnEnv.
      * I found that tcInstDecls1 had very clumsy error handling, so I
        put it together into TcInstDcls.doClsInstErrorChecks
  20. 29 Mar, 2016 1 commit
  21. 23 Mar, 2016 1 commit
  22. 21 Mar, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Track specified/invisible more carefully. · 35e93797
      eir@cis.upenn.edu authored
      In particular, this allows correct tracking of specified/invisible
      for variables in Haskell98 data constructors and in pattern synonyms.
      GADT-syntax constructors are harder, and are left until #11721.
      This was all inspired by Simon's comments to my fix for #11512,
      which this subsumes.
      Test case: ghci/scripts/TypeAppData
      [skip ci]  (The test case fails because of an unrelated problem
      fixed in the next commit.)
    • eir@cis.upenn.edu's avatar
      Make equality print better. (#11712) · 0b89064c
      eir@cis.upenn.edu authored
  23. 12 Mar, 2016 1 commit
    • Ben Gamari's avatar
      Simplify: Make generated names more useful · 4d791b4f
      Ben Gamari authored
      makeTrivial is responsible for concocting names during simplification.
      Previously, however, it would make no attempt to generate a name that
      might be useful to later readers of the resulting Core. Here we add a
      bit of state to SimplEnv: a finite depth stack of binders within which
      we are currently simplifying. We then derive generated binders from this
      See #11676.
      Open questions:
        * Is there a better way to accomplish this?
        * Is `maxContextDepth` too large/small?
      Test Plan: Validate, look at Core.
      Reviewers: austin, simonpj
      Reviewed By: simonpj
      Subscribers: thomie, simonpj
      Differential Revision: https://phabricator.haskell.org/D1970
      GHC Trac Issues: #11676
  24. 24 Feb, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Address #11471 by putting RuntimeRep in kinds. · d8c64e86
      eir@cis.upenn.edu authored
      See Note [TYPE] in TysPrim. There are still some outstanding
      pieces in #11471 though, so this doesn't actually nail the bug.
      This commit also contains a few performance improvements:
      * Short-cut equality checking of nullary type syns
      * Compare types before kinds in eqType
      * INLINE coreViewOneStarKind
      * Store tycon binders separately from kinds.
      This resulted in a ~10% performance improvement in compiling
      the Cabal package. No change in functionality other than
      performance. (This affects the interface file format, though.)
      This commit updates the haddock submodule.
  25. 18 Feb, 2016 1 commit
    • Ben Gamari's avatar
      Unwire Typeable representation types · 206a8bf4
      Ben Gamari authored
      In order to make this work I needed to shuffle around typechecking a bit
      such that `TyCon` and friends are available during compilation of
      GHC.Types.  I also did a bit of refactoring of `TcTypeable`.
      Test Plan: Validate
      Reviewers: simonpj, austin
      Subscribers: simonpj, thomie
      Differential Revision: https://phabricator.haskell.org/D1906
      GHC Trac Issues: #11120
  26. 12 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve pretty-printing of HsWrappers · d0846243
      Simon Peyton Jones authored
      Reduces un-neede parens.
      Also -fprint-typechecker-elaboration now makes type applications
      and casts in expressions also appear.  (Previously those were
      confusingly controlled by -fprint-explicit-coercions.)
  27. 18 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Refactoring on IdInfo and system derived names · ec8a188a
      Simon Peyton Jones authored
      Some modest refactoring, triggered in part by Trac #11051
      * Kill off PatSynId, ReflectionId in IdDetails
        They were barely used, and only for pretty-printing
      * Add helper function Id.mkExportedVanillaId, and use it
      * Polish up OccName.isDerivedOccName, as a predicate for
        definitions generated internally by GHC, which we
        might not want to show to the user.
      * Kill off unused OccName.mkDerivedTyConOcc
      * Shorten the derived OccNames for newtype and data
        instance axioms
      * A bit of related refactoring around newFamInstAxiomName
  28. 24 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Visible type application · 2db18b81
      eir@cis.upenn.edu authored
      This re-working of the typechecker algorithm is based on
      the paper "Visible type application", by Richard Eisenberg,
      Stephanie Weirich, and Hamidhasan Ahmed, to be published at
      This patch introduces -XTypeApplications, which allows users
      to say, for example `id @Int`, which has type `Int -> Int`. See
      the changes to the user manual for details.
      This patch addresses tickets #10619, #5296, #10589.
  29. 23 Dec, 2015 1 commit
  30. 17 Dec, 2015 1 commit
  31. 15 Dec, 2015 2 commits
  32. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
       * The type of `*` is now `*`. No more `BOX`.
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
       * The new extension `TypeInType` turns on the new user-facing
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
       * The new features are still quite experimental and may be in flux.
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
       * TODO: Update user manual.
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
  33. 01 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor treatment of wildcards · 1e041b73
      Simon Peyton Jones authored
      This patch began as a modest refactoring of HsType and friends, to
      clarify and tidy up exactly where quantification takes place in types.
      Although initially driven by making the implementation of wildcards more
      tidy (and fixing a number of bugs), I gradually got drawn into a pretty
      big process, which I've been doing on and off for quite a long time.
      There is one compiler performance regression as a result of all
      this, in perf/compiler/T3064.  I still need to look into that.
      * The principal driving change is described in Note [HsType binders]
        in HsType.  Well worth reading!
      * Those data type changes drive almost everything else.  In particular
        we now statically know where
             (a) implicit quantification only (LHsSigType),
                 e.g. in instance declaratios and SPECIALISE signatures
             (b) implicit quantification and wildcards (LHsSigWcType)
                 can appear, e.g. in function type signatures
      * As part of this change, HsForAllTy is (a) simplified (no wildcards)
        and (b) split into HsForAllTy and HsQualTy.  The two contructors
        appear when and only when the correponding user-level construct
        appears.  Again see Note [HsType binders].
        HsExplicitFlag disappears altogether.
      * Other simplifications
           - ExprWithTySig no longer needs an ExprWithTySigOut variant
           - TypeSig no longer needs a PostRn name [name] field
             for wildcards
           - PatSynSig records a LHsSigType rather than the decomposed
           - The mysterious 'GenericSig' is now 'ClassOpSig'
      * Renamed LHsTyVarBndrs to LHsQTyVars
      * There are some uninteresting knock-on changes in Haddock,
        because of the HsSyn changes
      I also did a bunch of loosely-related changes:
      * We already had type synonyms CoercionN/CoercionR for nominal and
        representational coercions.  I've added similar treatment for
        All just type synonyms but jolly useful.
      * I record-ised ForeignImport and ForeignExport
      * I improved the (poor) fix to Trac #10896, by making
        TcTyClsDecls.checkValidTyCl recover from errors, but adding a
        harmless, abstract TyCon to the envt if so.
      * I did some significant refactoring in RnEnv.lookupSubBndrOcc,
        for reasons that I have (embarrassingly) now totally forgotten.
        It had to do with something to do with import and export
      Updates haddock submodule.
  34. 22 Nov, 2015 1 commit
  35. 18 Nov, 2015 1 commit
    • msosn's avatar
      Fix inconsistent pretty-printing of type families · c61759d5
      msosn authored
      After the changes, the three functions used to print type families
      were identical, so they are refactored into one.
      Original RHSs of data instance declarations are recreated and
      printed in user error messages.
      RHSs containing representation TyCons are printed in the
      Coercion Axioms section in a typechecker dump.
      Add vbar to the list of SDocs exported by Outputable.
      Replace all text "|" docs with it.
      Fixes #10839
      Reviewers: goldfire, jstolarek, austin, bgamari
      Reviewed By: jstolarek
      Subscribers: jstolarek, thomie
      Differential Revision: https://phabricator.haskell.org/D1441
      GHC Trac Issues: #10839
  36. 01 Nov, 2015 1 commit