1. 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
  2. 17 Sep, 2015 1 commit
  3. 16 Jul, 2015 1 commit
  4. 18 Jun, 2015 1 commit
    • Simon Peyton Jones's avatar
      Remove some horrible munging of origins for Coercible · 02bac025
      Simon Peyton Jones authored
      I just didn't think it was buying enough for all the cruft it caused.
      We can put some back if people start complaining about poor error
      messages. I forget quite how I tripped over this but I got sucked in.
      
      * Lots of tidying up in TcErrors
      
      * Rename pprArisingAt to pprCtLoc, by analogy with pprCtOrigin
      
      * Remove CoercibleOrigin data constructor from CtOrigin
      
      * Make relevantBindings return a Ct with a zonked
        and tidied CtOrigin
      
      * Add to TcRnTypes
            ctOrigin   :: Ct -> CtOrigin
            ctEvOrigin :: CtEvidence -> CtOrigin
            setCtLoc   :: Ct -> CtLoc -> Ct
      02bac025
  5. 25 Apr, 2015 1 commit
  6. 24 Apr, 2015 2 commits
  7. 22 Apr, 2015 1 commit
  8. 23 Mar, 2015 2 commits
    • eir@cis.upenn.edu's avatar
      Do proper depth checking in the flattener to avoid looping. · c1edbdfd
      eir@cis.upenn.edu authored
      This implements (roughly) the plan put forward in comment:14:ticket:7788,
      fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079.
      There are some regressions w.r.t. GHC 7.8, but only with pathological type
      families (like F a = F a). This also (hopefully -- don't have a test case)
      fixes #10158. Unsolved problems include #10184 and #10185, which are both
      known deficiencies of the approach used here.
      
      As part of this change, the plumbing around detecting infinite loops has
      changed. Instead of -fcontext-stack and -ftype-function-depth, we now have
      one combined -freduction-depth parameter. Setting it to 0 disbales the
      check, which is now the recommended way to get (terminating) code to
      typecheck in releases. (The number of reduction steps may well change between
      minor GHC releases!)
      
      This commit also introduces a new IntWithInf type in BasicTypes
      that represents an integer+infinity. This type is used in a few
      places throughout the code.
      
      Tests in
        indexed-types/should_fail/T7788
        indexed-types/should_fail/T8550
        indexed-types/should_fail/T9554
        indexed-types/should_compile/T10079
        indexed-types/should_compile/T10139
        typecheck/should_compile/T10184  (expected broken)
        typecheck/should_compile/T10185  (expected broken)
      
      This commit also changes performance testsuite numbers, for the better.
      c1edbdfd
    • Herbert Valerio Riedel's avatar
      Minor bump `base` version to 4.8.1.0 · 7035ff87
      Herbert Valerio Riedel authored
      We've accumulated enough to justify a minor version bump to 4.8.1.0,
      but not enough to justify a major version bump yet as far as I can see.
      7035ff87
  9. 20 Mar, 2015 1 commit
  10. 04 Mar, 2015 1 commit
    • Simon Peyton Jones's avatar
      A raft of small changes associated with -XConstrainedClassMethods · f66e0e69
      Simon Peyton Jones authored
      See Trac #7854.  Specifically:
      
      * Major clean up and simplification of check_op in checkValidClass;
        specifically
           - use checkValidType on the entire method-selector type to detect
             ambiguity
           - put a specific test for -XConstrainedClassMethods
      
      * Make -XConstrainedClassMethods be implied by -XMultiParamTypeClasses
        (a bit ad-hoc but see #7854), and document in the user manual.
      
      * Do the checkAmbiguity test just once in TcValidity.checkValidType,
        rather than repeatedly at every level. See Note [When to call checkAmbiguity]
      
      * Add -XAllowAmbiguousTypes in GHC.IP, since 'ip' really is ambiguous.
        (It's a rather magic function.)
      
      * Improve location info for check_op in checkValidClass
      
      * Update quite a few tests, which had genuinely-ambiguous class
        method signatures.  Some I fixed by making them unambiguous; some
        by adding -XAllowAmbiguousTypes
      f66e0e69
  11. 12 Dec, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Rewrite `Coercible` solver · 0cc47eb9
      eir@cis.upenn.edu authored
      Summary:
      This is a rewrite of the algorithm to solve for Coercible "instances".
      
      A preliminary form of these ideas is at
      https://ghc.haskell.org/trac/ghc/wiki/Design/NewCoercibleSolver
      
      The basic idea here is that the `EqPred` constructor of `PredTree`
      now is parameterised by a new type `EqRel` (where
      `data EqRel = NomEq | ReprEq`). Thus, every equality constraint can
      now talk about nominal equality (the usual case) or representational
      equality (the `Coercible` case).
      
      This is a change from the previous
      behavior where `Coercible` was just considered a regular class with
      a special case in `matchClassInst`.
      
      Because of this change, representational equalities are now
      canonicalized just like nominal ones, allowing more equalities
      to be solved -- in particular, the case at the top of #9117.
      
      A knock-on effect is that the flattener must be aware of the
      choice of equality relation, because the inert set now stores
      both representational inert equalities alongside the nominal
      inert equalities. Of course, we can use representational equalities
      to rewrite only within another representational equality --
      thus the parameterization of the flattener.
      
      A nice side effect of this change is that I've introduced a new
      type `CtFlavour`, which tracks G vs. W vs. D, removing some ugliness
      in the flattener.
      
      This commit includes some refactoring as discussed on D546.
      It also removes the ability of Deriveds to rewrite Deriveds.
      
      This fixes bugs #9117 and #8984.
      
      Reviewers: simonpj, austin, nomeata
      
      Subscribers: carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D546
      
      GHC Trac Issues: #9117, #8984
      0cc47eb9
  12. 20 Nov, 2014 1 commit
  13. 12 Nov, 2014 3 commits
  14. 04 Nov, 2014 1 commit
  15. 07 Oct, 2014 1 commit
  16. 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
  17. 29 Aug, 2014 1 commit
  18. 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
  19. 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
  20. 11 Jun, 2014 2 commits
    • eir@cis.upenn.edu's avatar
      Fix #9062. · e79e2c39
      eir@cis.upenn.edu authored
      Removed (pprEqPred (coercionKind co)) in favor of
      (pprType (coercionType co)).
      
      Also had to make "~R#" a *symbolic* identifier and BuiltInSyntax
      to squelch prefix notation and module prefixes in output. These
      changes are both sensible independent of #9062.
      e79e2c39
    • eir@cis.upenn.edu's avatar
      Make FunPtr's role be phantom; add comments. · 9e6c6b42
      eir@cis.upenn.edu authored
      This change also updates castFunPtr to make it free at runtime.
      This fixes #9163.
      9e6c6b42
  21. 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
  22. 28 Apr, 2014 1 commit
    • Simon Peyton Jones's avatar
      Print for-alls more often (Trac #9018) · 2f3ea952
      Simon Peyton Jones authored
      We now display the foralls of a type if any of the type variables
      is polykinded.  This put kind polymorphism "in your face" a bit more
      often, but eliminates a lot of head scratching.
      
      The user manual reflects the new behaviour.
      2f3ea952
  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
  25. 19 Mar, 2014 1 commit
  26. 25 Feb, 2014 1 commit
  27. 13 Feb, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #8773. · 13829758
      eir@cis.upenn.edu authored
      To make a role annotation on a class asserting a role other than
      nominal, you now need -XIncoherentInstances. See the ticket for
      more information as to why this is a good idea.
      13829758
  28. 04 Dec, 2013 1 commit
  29. 02 Dec, 2013 2 commits
  30. 22 Nov, 2013 1 commit
  31. 23 Oct, 2013 2 commits
  32. 08 Oct, 2013 1 commit