1. 29 Mar, 2016 1 commit
  2. 23 Mar, 2016 1 commit
  3. 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.
      d8c64e86
  4. 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.)
      d0846243
  5. 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
      ec8a188a
  6. 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
      ESOP'16.
      
      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.
      2db18b81
  7. 17 Dec, 2015 1 commit
  8. 15 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Narrow scope of special-case for unqualified printing of names in core libraries · e2c91738
      Ben Gamari authored
      Commit 547c5971 modifies the
      pretty-printer to render names from a set of core packages (`base`,
      `ghc-prim`, `template-haskell`) as unqualified. The idea here was that
      many of these names typically are not in scope but are well-known by the
      user and therefore qualification merely introduces noise.
      
      This, however, is a very large hammer and potentially breaks any
      consumer who relies on parsing GHC output (hence #11208). This commit
      partially reverts this change, now only printing `Constraint` (which
      appears quite often in errors) as unqualified.
      
      Fixes #11208.
      
      Updates tests in `array` submodule.
      
      Test Plan: validate
      
      Reviewers: hvr, thomie, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1619
      
      GHC Trac Issues: #11208
      e2c91738
  9. 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
         features.
      
       * 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.
      67465497
  10. 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
      c61759d5
  11. 01 Nov, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Bump ghc-prim version to 0.5.0.0 (closes #11043) · 84bf1eba
      Herbert Valerio Riedel authored
      This also needs to update the primitive/vector submodules in order to
      relax upper bounds on ghc-prim.
      
      Like in f8ba4b55, a mass-rewrite in testsuite/ via
      
        sed -i s,ghc-prim-0.4.0.0,ghc-prim-0.5.0.0,g $(git grep -Fl 'ghc-prim-0.4.0.0')
      
      was performed.
      84bf1eba
    • Herbert Valerio Riedel's avatar
      Bump `base` version to 4.9.0.0 (closes #11026) · f8ba4b55
      Herbert Valerio Riedel authored
      This also relaxes a few upper bounds on base in the ghc.git repo;
      
      This required a mass-rewrite in testsuite/
      
        sed -i s,base-4.8.2.0,base-4.9.0.0,g $(git grep -Fl 'base-4.8.2.0')
      
      because it turns out the testsuite is still sensitive to package version
      changes.
      f8ba4b55
  12. 30 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · 91c6b1f5
      Ben Gamari authored
      This is the second attempt at merging D757.
      
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing
      stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T1969:    GHC allocates 19% more
       * T4801:    GHC allocates 13% more
       * T5321FD:  GHC allocates 13% more
       * T9675:    GHC allocates 11% more
       * T783:     GHC allocates 11% more
       * T5642:    GHC allocates 10% more
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might
      be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I
      have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Updates haddock submodule
      
      Test Plan: Let Harbormaster validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1404
      
      GHC Trac Issues: #9858
      91c6b1f5
  13. 29 Oct, 2015 2 commits
    • Ben Gamari's avatar
      Revert "Generate Typeable info at definition sites" · bbaf76f9
      Ben Gamari authored
      This reverts commit bef2f03e.
      
      This merge was botched
      
      Also reverts haddock submodule.
      bbaf76f9
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · bef2f03e
      Ben Gamari authored
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T3294:   GHC allocates 110% more (filed #11030 to track this)
       * T1969:   GHC allocates 30% more
       * T4801:   GHC allocates 14% more
       * T5321FD: GHC allocates 13% more
       * T783:    GHC allocates 12% more
       * T9675:   GHC allocates 12% more
       * T5642:   GHC allocates 10% more
       * T9961:   GHC allocates 6% more
      
       * T9203:   Program allocates 54% less
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Requires update of the haddock submodule.
      
      Differential Revision: https://phabricator.haskell.org/D757
      bef2f03e
  14. 25 Apr, 2015 1 commit
  15. 23 Mar, 2015 1 commit
  16. 20 Mar, 2015 1 commit
  17. 04 Nov, 2014 1 commit
  18. 09 Sep, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Bump `base` version to 4.8.0.0 for real · c6f502b2
      Herbert Valerio Riedel authored
      This commit updates several submodules in order to bump
      the upper bounds on `base` of most boot packages
      
      Moreover, this updates some of the test-suite cases which have
      version numbers hardcoded within.
      
      However, I'm not sure if this commit didn't introduce the following
      two test-failures
      
         ghc-api  T8628 [bad stdout] (normal)
         ghc-api  T8639_api [bad stdout] (normal)
      
      This needs investigation
      c6f502b2
  19. 29 Aug, 2014 1 commit
  20. 22 Aug, 2014 1 commit
    • Edward Z. Yang's avatar
      Do not zero out version number when processing wired-in packages. · 22520cd7
      Edward Z. Yang authored
      Summary:
      Previously, GHC would look for instances of wired-in packages in the
      in-memory package database and null out the version number.  This was
      necessary when the sourcePackageId was used to determine the linker
      symbols; however, we now use a package key, so only that needs to be
      updated.
      
      Long-term, we can remove this hack by ensuring that Cabal actually records
      the proper package key in the database.  This will also fix an unrelated
      hack elsewhere.
      
      Keeping version numbers means that wired in packages get rendered differently
      when output by GHC.  This is the source of all the test-case output changes.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: hvr, austin
      
      Subscribers: simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D170
      22520cd7
  21. 31 Jul, 2014 1 commit
    • Simon Peyton Jones's avatar
      Complete work on new OVERLAPPABLE/OVERLAPPING pragmas (Trac #9242) · 1ae5fa45
      Simon Peyton Jones authored
      * Deprecate -XOverlappingInstances
      
      * Update test suite.  Several tests even had entirely unnecessary
        uses of -XOverlappingInstances
      
      * Update user manual with a careful description of the instance
        resolution story
      
      * Fix an outright bug in the handling of duplidate instances in GHCi,
        which are meant to silently overwrite the earlier duplicate. The
        logic was right for family instances but was both more complicated,
        and plain wrong, for class instances.  (If you are interested, the
        bug was that we were eliminating the duplicate from the InstEnv, but
        not from the [ClsInst] held in tcg_insts.)  Test is ghci044a.
      1ae5fa45
  22. 03 Jun, 2014 1 commit
    • Simon Peyton Jones's avatar
      Do pretty-printing of TyThings via IfaceDecl (Trac #7730) · b4856f9f
      Simon Peyton Jones authored
      All the initial work on this was done fy 'archblob' (fcsernik@gmail.com);
      thank you!
      
      I reviewed the patch, started some tidying, up and then ended up in a huge
      swamp of changes, not all of which I can remember now.  But:
      
      * To suppress kind arguments when we have -fno-print-explicit-kinds,
          - IfaceTyConApp argument types are in a tagged list IfaceTcArgs
      
      * To allow overloaded types to be printed with =>, add IfaceDFunTy to IfaceType.
      
      * When printing data/type family instances for the user, I've made them
        print out an informative RHS, which is a new feature. Thus
              ghci> info T
              data family T a
              data instance T Int = T1 Int Int
              data instance T Bool = T2
      
      * In implementation terms, pprIfaceDecl has just one "context" argument,
        of type IfaceSyn.ShowSub, which says
             - How to print the binders of the decl
               see note [Printing IfaceDecl binders] in IfaceSyn
             - Which sub-comoponents (eg constructors) to print
      
      * Moved FastStringEnv from RnEnv to OccName
      
      It all took a ridiculously long time to do.  But it's done!
      b4856f9f
  23. 09 Apr, 2014 1 commit
  24. 05 Apr, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #8958. · d468cd37
      eir@cis.upenn.edu authored
      We now do role inference on stupid datatype contexts, allowing a
      lightweight role annotation syntax.
      d468cd37