1. 17 Jan, 2017 1 commit
    • David Feuer's avatar
      Split mkInlineUnfolding into two functions · d360ec39
      David Feuer authored
      Previously, `mkInlineUnfolding` took a `Maybe` argument indicating
      whether the caller requested a specific arity.  This was not
      self-documenting at call sites. Now we distinguish between
      `mkInlineUnfolding` and `mkInlineUnfoldingWithArity`.
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2933
      d360ec39
  2. 02 Jan, 2017 1 commit
  3. 21 Dec, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix 'SPECIALISE instance' · 1a4c04b1
      Simon Peyton Jones authored
      Trac #12944 showed that the DsBinds code that implemented a
      SPECIALISE pragma was inadequate if the constraints solving
      added let-bindings for dictionaries.  The result was that
      we ended up with an unbound dictionary in a DFunUnfolding -- and
      Lint didn't even check for that!
      
      Fixing this was not entirely straightforward
      
      * In DsBinds.dsSpec we use a new function
           TcEvidence.collectHsWrapBinders
        to pick off the lambda binders from the HsWapper
      
      * dsWrapper now returns a (CoreExpr -> CoreExpr) function
      
      * CoreUnfold.specUnfolding now takes a (CoreExpr -> CoreExpr)
        function it can use to specialise the unfolding.
      
      On the whole the code is simpler than before.
      1a4c04b1
  4. 12 Dec, 2016 1 commit
    • Simon Peyton Jones's avatar
      Refactor pruning of implication constraints · 818e027e
      Simon Peyton Jones authored
      We try to prune solved implication constraints, but it's a
      bit tricky because of our desire to correctly report unused
      'givens'.  This patch improves matters a bit... in tracig some
      other bug I saw lots of empty constraints lying around!
      818e027e
  5. 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
  6. 25 Nov, 2016 1 commit
    • Simon Peyton Jones's avatar
      Use TyVars in a DFunUnfolding · edbe8319
      Simon Peyton Jones authored
      En route to something else I discovered that TcInstDcls.addDFunPrags
      was building a DFunUnfolding that had TcTyVars in it.  They should
      never survive beyond type checking.  It was harmeless, but now affects
      type pretty-printing.
      
      This patch fixes it.
      edbe8319
  7. 15 Nov, 2016 1 commit
  8. 21 Oct, 2016 2 commits
    • 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
         refactoring.
      
      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
         better.
      
      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
         correct.
      
      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
          'termEvidenceAllowed')
      
      All these changes led to quite bit of error message wibbling
      3f5673f3
    • Simon Peyton Jones's avatar
      Comments and trivial refactoring · 82efad78
      Simon Peyton Jones authored
      82efad78
  9. 19 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Test for newtype with unboxed argument · 1f09c16c
      Simon Peyton Jones authored
      Newtypes cannot (currently) have an unboxed argument type.
      But Trac #12729 showed that this was only being checked for
      newtypes in H98 syntax; in GADT snytax they were let through.
      
      This patch moves the test to checkValidDataCon, where it properly
      belongs.
      1f09c16c
  10. 10 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Move zonking out of tcFamTyPats · 76a5477b
      Simon Peyton Jones authored
      In tcFamTyPats we were zonking from the TcType world to the
      Type world, ready to build the results into a CoAxiom (which
      should have no TcType stuff.  But the 'thing_inside' for
      tcFamTyPats also must be zonked, and that zonking must have
      the ZonkEnv from the binders zonked tcFamTyPats.
      
      Ugh.  This caused an assertion failure (with DEBUG on) in
      RaeBlobPost and TypeLevelVec, both in tests/dependent, as
      shown in Trac #12682.  Why it hasn't shown up before now
      is obscure to me.
      
      So I moved the zonking stuff out of tcFamTyPats to its
      three call sites, where we can do it all together. Very
      slightly longer, but much more robust.
      76a5477b
  11. 01 Oct, 2016 1 commit
    • Ryan Scott's avatar
      Implement deriving strategies · 9e862765
      Ryan Scott authored
      Allows users to explicitly request which approach to `deriving` to use
      via keywords, e.g.,
      
      ```
      newtype Foo = Foo Bar
        deriving Eq
        deriving stock    Ord
        deriving newtype Show
      ```
      
      Fixes #10598. Updates haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin,
      erikd, simonmar
      
      Reviewed By: alanz, bgamari, simonpj
      
      Subscribers: thomie, mpickering, oerjan
      
      Differential Revision: https://phabricator.haskell.org/D2280
      
      GHC Trac Issues: #10598
      9e862765
  12. 26 Aug, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix scoping of type variables in instances · 0050aff2
      Simon Peyton Jones authored
      This fixes Trac #12531:
      
         class Foo x where
           foo :: forall a . x a -> x a
           default foo :: forall b . x b -> x b
           foo x = go
             where go :: x b
                   go = undefined
      
      We want 'b' to scope over the code for 'foo', but we were
      using 'a' instead.
      0050aff2
  13. 18 Jul, 2016 1 commit
  14. 30 Jun, 2016 1 commit
    • Edward Z. Yang's avatar
      Axe RecFlag on TyCons. · b8b3e30a
      Edward Z. Yang authored
      Summary:
      This commit removes the information about whether or not
      a TyCon is "recursive", as well as the code responsible
      for calculating this information.
      
      The original trigger for this change was complexity regarding
      how we computed the RecFlag for hs-boot files.  The problem
      is that in order to determine if a TyCon is recursive or
      not, we need to determine if it was defined in an hs-boot
      file (if so, we conservatively assume that it is recursive.)
      
      It turns that doing this is quite tricky.  The "obvious"
      strategy is to typecheck the hi-boot file (since we are
      eventually going to need the typechecked types to check
      if we properly implemented the hi-boot file) and just extract
      the names of all defined TyCons from the ModDetails, but
      this actually does not work well if Names from the hi-boot
      file are being knot-tied via if_rec_types: the "extraction"
      process will force thunks, which will force the typechecking
      process earlier than we have actually defined the types
      locally.
      
      Rather than work around all this trickiness (it certainly
      can be worked around, either by making interface loading
      MORE lazy, or just reading of the set of defined TyCons
      directly from the ModIface), we instead opted to excise
      the source of the problem, the RecFlag.
      
      For one, it is not clear if the RecFlag even makes sense,
      in the presence of higher-orderness:
      
          data T f a = MkT (f a)
      
      T doesn't look recursive, but if we instantiate f with T,
      then it very well is!  It was all very shaky.
      
      So we just don't bother anymore.  This has two user-visible
      implications:
      
      1. is_too_recursive now assumes that all TyCons are
      recursive and will bail out in a way that is still mysterious
      to me if there are too many TyCons.
      
      2. checkRecTc, which is used when stripping newtypes to
      get to representation, also assumes all TyCons are
      recursive, and will stop running if we hit the limit.
      
      The biggest risk for this patch is that we specialize less
      than we used to; however, the codeGen tests still seem to
      be passing.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2360
      b8b3e30a
  15. 27 Jun, 2016 1 commit
  16. 25 Jun, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      s/Invisible/Inferred/g s/Visible/Required/g · 5fdb854c
      eir@cis.upenn.edu authored
      This renames VisibilityFlag from
      
      > data VisibilityFlag = Visible | Specified | Invisible
      
      to
      
      > data ArgFlag = Required | Specified | Inferred
      
      The old name was quite confusing, because both Specified
      and Invisible were invisible! The new names are hopefully clearer.
      5fdb854c
  17. 24 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve typechecking of instance defaults · d2958bd0
      Simon Peyton Jones authored
      In an instance declaration when you don't specify the code for a
      method, GHC fills in from the default binding in the class.
      The type of the default method can legitmiately be ambiguous ---
      see Note [Default methods in instances] in TcInstDcls --- so
      typechecking it can be tricky.
      
      Trac #12220 showed that although we were dealing with that ambiguity
      for /vanilla/ default methods, we were not doing so for /generic/
      default methods.  Moreover we were dealing with it clumsily, by
      generating post-typechecked code.
      
      This patch fixes the bug AND deletes code!  We now use the same code
      path for both vanilla and generic default methods; and generate
      /pre-typechecked/ code in both cases.  The key trick is that we can use
      Visible Type Application to deal with the ambiguity, which wasn't
      possible before.  Hooray.
      
      There is a small hit to performance in compiler/perf/T1969 which
      consists of nothing BUT instance declarations with several default
      methods to fill, which we now have to typecheck. The actual hit is
      from 724 -> 756 or 4% in that extreme example.  Real world programs
      have vastly fewer instance decls.
      d2958bd0
  18. 22 Jun, 2016 1 commit
  19. 15 Jun, 2016 2 commits
    • Simon Peyton Jones's avatar
      Major patch to introduce TyConBinder · e368f326
      Simon Peyton Jones authored
      Before this patch, following the TypeInType innovations,
      each TyCon had two lists:
        - tyConBinders :: [TyBinder]
        - tyConTyVars  :: [TyVar]
      
      They were in 1-1 correspondence and contained
      overlapping information.  More broadly, there were many
      places where we had to pass around this pair of lists,
      instead of a single list.
      
      This commit tidies all that up, by having just one list of
      binders in a TyCon:
      
        - tyConBinders :: [TyConBinder]
      
      The new data types look like this:
      
        Var.hs:
           data TyVarBndr tyvar vis = TvBndr tyvar vis
           data VisibilityFlag = Visible | Specified | Invisible
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
      
        TyCon.hs:
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
      
           data TyConBndrVis
             = NamedTCB VisibilityFlag
             | AnonTCB
      
        TyCoRep.hs:
           data TyBinder
             = Named TyVarBinder
             | Anon Type
      
      Note that Var.TyVarBdr has moved from TyCoRep and has been
      made polymorphic in the tyvar and visiblity fields:
      
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
              -- Used in ForAllTy
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
              -- Used in TyCon
      
           type IfaceForAllBndr  = TyVarBndr IfaceTvBndr VisibilityFlag
           type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
               -- Ditto, in interface files
      
      There are a zillion knock-on changes, but everything
      arises from these types.  It was a bit fiddly to get the
      module loops to work out right!
      
      Some smaller points
      ~~~~~~~~~~~~~~~~~~~
      * Nice new functions
          TysPrim.mkTemplateKiTyVars
          TysPrim.mkTemplateTyConBinders
        which help you make the tyvar binders for dependently-typed
        TyCons.  See comments with their definition.
      
      * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
        was making an assumption about the order of the kind variables in the
        kind of GHC.Generics.(:.:).  I fixed this; see TcGenGenerics.mkComp.
      e368f326
    • Simon Peyton Jones's avatar
      Re-add FunTy (big patch) · 77bb0927
      Simon Peyton Jones authored
      With TypeInType Richard combined ForAllTy and FunTy, but that was often
      awkward, and yielded little benefit becuase in practice the two were
      always treated separately.  This patch re-introduces FunTy.  Specfically
      
      * New type
          data TyVarBinder = TvBndr TyVar VisibilityFlag
        This /always/ has a TyVar it.  In many places that's just what
        what we want, so there are /lots/ of TyBinder -> TyVarBinder changes
      
      * TyBinder still exists:
          data TyBinder = Named TyVarBinder | Anon Type
      
      * data Type = ForAllTy TyVarBinder Type
                  | FunTy Type Type
                  |  ....
      
      There are a LOT of knock-on changes, but they are all routine.
      
      The Haddock submodule needs to be updated too
      77bb0927
  20. 13 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve typechecking of let-bindings · 15b9bf4b
      Simon Peyton Jones authored
      This major commit was initially triggered by #11339, but it spiraled
      into a major review of the way in which type signatures for bindings
      are handled, especially partial type signatures.  On the way I fixed a
      number of other bugs, namely
         #12069
         #12033
         #11700
         #11339
         #11670
      
      The main change is that I completely reorganised the way in which type
      signatures in bindings are handled. The new story is in TcSigs
      Note [Overview of type signatures].  Some specific:
      
      * Changes in the data types for signatures in TcRnTypes:
        TcIdSigInfo and new TcIdSigInst
      
      * New module TcSigs deals with typechecking type signatures
        and pragmas. It contains code mostly moved from TcBinds,
        which is already too big
      
      * HsTypes: I swapped the nesting of HsWildCardBndrs
        and HsImplicitBndsrs, so that the wildcards are on the
        oustide not the insidde in a LHsSigWcType.  This is just
        a matter of convenient, nothing deep.
      
      There are a host of other changes as knock-on effects, and
      it all took FAR longer than I anticipated :-).  But it is
      a significant improvement, I think.
      
      Lots of error messages changed slightly, some just variants but
      some modest improvements.
      
      New tests
      
      * typecheck/should_compile
          * SigTyVars: a scoped-tyvar test
          * ExPat, ExPatFail: existential pattern bindings
          * T12069
          * T11700
          * T11339
      
      * partial-sigs/should_compile
          * T12033
          * T11339a
          * T11670
      
      One thing to check:
      
      * Small change to output from ghc-api/landmines.
        Need to check with Alan Zimmerman
      15b9bf4b
  21. 06 Jun, 2016 1 commit
    • Alan Zimmerman's avatar
      Merge MatchFixity and HsMatchContext · a13cb279
      Alan Zimmerman authored
      Summary:
      MatchFixity was introduced to facilitate use of API Annotations.
      
      HsMatchContext does the same thing with more detail, but is chased
      through all over the place to provide context when processing a Match.
      
      Since we already have MatchFixity in the Match, it may as well provide
      the full context.
      
      updates submodule haddock
      
      Test Plan: ./validate
      
      Reviewers: austin, goldfire, bgamari
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2271
      
      GHC Trac Issues: #12105
      
      (cherry picked from commit 306ecad5)
      a13cb279
  22. 06 May, 2016 1 commit
    • Simon Peyton Jones's avatar
      Use tcExtendGlobalValEnv for default methods · 990ce8c9
      Simon Peyton Jones authored
      We add the default method Ids to the global type envt in
      tcAddImplicits; and then again in tcInstDcls2 (for reasons
      explained there).  But for some reason in the latter case
      we added them to the /local/ type envt, via tcExtendLetEnv.
      
      This patch just uses tcExtendGlobalValEnv consistently
      for both.
      
      (I found this when reviewing slightly-awkward code from Facundo's
      static-form error-message patch; turned out that the awkwardness
      came back to this inconsistency in the handling of default
      methods.)
      990ce8c9
  23. 29 Apr, 2016 1 commit
  24. 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
      353d8ae6
  25. 19 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      Tighten checking for associated type instances · 8136a5cb
      Simon Peyton Jones authored
      This patch finishes off Trac #11450.  Following debate on that ticket,
      the patch tightens up the rules for what the instances of an
      associated type can look like.  Now they must match the instance
      header exactly. Eg
      
         class C a b where
          type T a x b
      
      With this class decl, if we have an instance decl
        instance C ty1 ty2 where ...
      then the type instance must look like
           type T ty1 v ty2 = ...
      with exactly
        - 'ty1' for 'a'
        -  'ty2' for 'b', and
        - a variable for 'x'
      
      For example:
      
        instance C [p] Int
          type T [p] y Int = (p,y,y)
      
      Previously we allowed multiple instance equations and now, in effect,
      we don't since they would all overlap.  If you want multiple cases,
      use an auxiliary type family.
      
      This is consistent with the treatment of generic-default instances,
      and the user manual always said "WARNING: this facility (multiple
      instance equations may be withdrawn in the future".
      
      I also improved error messages, and did other minor refactoring.
      8136a5cb
  26. 07 Apr, 2016 1 commit
  27. 23 Mar, 2016 1 commit
  28. 21 Mar, 2016 1 commit
    • 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.)
      35e93797
  29. 25 Feb, 2016 1 commit
    • barrucadu's avatar
      Print which warning-flag controls an emitted warning · bb5afd3c
      barrucadu authored
      Both gcc and clang tell which warning flag a reported warning can be
      controlled with, this patch makes ghc do the same. More generally, this
      allows for annotated compiler output, where an optional annotation is
      displayed in brackets after the severity.
      
      This also adds a new flag `-f(no-)show-warning-groups` to control
      whether to show which warning-group (such as `-Wall` or `-Wcompat`)
      a warning belongs to. This flag is on by default.
      
      This implements #10752
      
      Reviewed By: quchen, bgamari, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1943
      bb5afd3c
  30. 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
  31. 18 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve piResultTys and friends · 4d031cf9
      Simon Peyton Jones authored
      Several things here:
      
      * Re-implement piResultTys so that its substitution has
        the correct in-scope set
      
        That means paying close attention to performance, since as we
        discovered in Trac #11371, it's a heavily used function and
        is often used on ordinary function types, with no foralls to
        worry about substituting.
      
      * Kill off applyTys, which was just the same as piResultTys.
      
      * Re-engineer MkCore.mkCoreApps so that it calls piResultTys,
        rather than repeatedly calling piResultTy.
      4d031cf9
  32. 15 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      A tiny, outright bug in tcDataFamInstDecl · e2f7d777
      Simon Peyton Jones authored
      This bug was revealed by Trac #11362.  It turns out that in my patch
      for Trac #11148 (namely 1160dc51), I failed to turn one occurrence of
      tvs' into full_tvs.  Sigh.  This is tricky stuff and it cost me
      several hours to page it back in and figure out what was happening.
      
      The result was a CoAxiom whose lhs had rhs had different kinds.  Eeek!
      
      Anyway it's fixed.
      
      I also added an ASSERT, in FamInst.newFamInst, that trips on such
      bogus CoAxioms.
      e2f7d777
  33. 12 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Simplify AbsBinds wrapping · c6485d5e
      Simon Peyton Jones authored
      In poking Trac #11414 I found myself sinking into the abe_inst_wrap
      swamp.  What is this strange thing?  (It turned out that #11414 was
      breaking because of it.)
      
      Thrillingly, I found a way to sweep it away again, putting the deep
      instantation into tcMonoBinds instead of mkExport; and it turned out
      that the fun_co_fn field of FunBind was already there ready to receive
      exactly this wrapper. Hooray.  Result
      
      * Death to abe_inst_wrap
      * Death to mbi_orig
      * Death to the plumbing in tcPolyInfer that did the
        deep instantiation
      
      I did find that I had to re-engineer the treatment of instance type
      signatures (again), but the result looks more modular and robust to
      me.
      
      And #11414 is fixed.
      c6485d5e
  34. 08 Feb, 2016 2 commits
    • Simon Peyton Jones's avatar
      Define mkTvSubst, and use it · fac0efc3
      Simon Peyton Jones authored
         mkTvSubst :: InScopeSet -> TvSubstEnv -> TCvSubst
      produces a TCvSubst with an empty CvSubstEnv
      fac0efc3
    • Simon Peyton Jones's avatar
      Allow foralls in instance decls · 2cf3cac6
      Simon Peyton Jones authored
      This patch finally makes it possible to have explicit
      foralls in an instance decl
         instance forall (a :: *). Eq a => Eq [a] where ...
      
      This is useful to allow kind signatures or indeed
      explicicit kind for-alls; see Trac #11519
      
      I thought it would be really easy, because an instance
      declaration already contains an actual HsSigType, so all
      the syntactic baggage is there.  But in fact it turned
      out that instance declarations were kind-checked a
      little differently, because the body kind of the forall
      is 'Constraint' rather than '*'.
      
      So I fixed that.  There a slight kludge
      (see Note [Body kind of a HsQualTy], but it's still a
      significant improvement.
      
      I also did the usual other round of refactoring,
      improved a few error messages, tidied up comments etc.
      The only significant aspect of all that was
      
        * Kill mkNakedSpecSigmaTy, mkNakedPhiTy, mkNakedFunTy
          These function names suggest that they do something
          complicated, but acutally they do nothing. So I
          killed them.
      
        * Swap the arg order of mkNamedBinder, just so that it is
          convenient to say 'map (mkNamedBinder Invisible) tvs'
      
        * I had to improve isPredTy, to deal with (illegal)
          types like
             (Eq a => Eq [a]) => blah
          See Note [isPeredTy complications] in Type.hs
      
      Still to come: user manual documentation for the
      instance-decl change.
      2cf3cac6
  35. 27 Jan, 2016 2 commits
    • niteria's avatar
      Rename "open" subst functions · 5dcae88b
      niteria authored
      This is the renaming that @simonpj requested:
      ```
      · zipOpenTCvSubst  -> zipTvSubst   (It only deals with tyvars)
      
      · zipOpenTCvSubstCoVars -> zipCvSubst   (it only deals with
      covars)
      
      · zipOpenTCvSubstBinders ->  zipTyBinderSubst  (it only deals
      with TyBinders, not covars)
      ```
      plus the `mk` variant.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Subscribers: thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D1853
      
      GHC Trac Issues: #11371
      5dcae88b
    • eir@cis.upenn.edu's avatar
      Refactor the typechecker to use ExpTypes. · 00cbbab3
      eir@cis.upenn.edu authored
      The idea here is described in [wiki:Typechecker]. Briefly,
      this refactor keeps solid track of "synthesis" mode vs
      "checking" in GHC's bidirectional type-checking algorithm.
      When in synthesis mode, the expected type is just an IORef
      to write to.
      
      In addition, this patch does a significant reworking of
      RebindableSyntax, allowing much more freedom in the types
      of the rebindable operators. For example, we can now have
      `negate :: Int -> Bool` and
      `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic
      is in tcSyntaxOp.
      
      This addresses tickets #11397, #11452, and #11458.
      
      Tests:
        typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458}
        th/T11452
      00cbbab3
  36. 25 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Refactor validity checking for type/data instances · 746764cc
      Simon Peyton Jones authored
      I found that there was some code duplication going on,
      so I've put more into the shared function checkValidFamPats.
      
      I did some refactoring in checkConsistentFamInst too,
      preparatory to #11450; the error messages change a little
      but no change in behaviour.
      746764cc