1. 21 May, 2018 1 commit
    • Ben Gamari's avatar
      ghc-prim: Bump version · e1fd9461
      Ben Gamari authored
      unpackClosure#'s behavior and type has changed. This caused a CPP guard
      in the new ghc-heap package to fail when bootstrapping with GHC 8.4.
      Test Plan: Validate bootstrapping with GHC 8.4
      Reviewers: RyanGlScott
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4716
  2. 05 May, 2018 1 commit
    • Sebastian Graf's avatar
      Add 'addWordC#' PrimOp · 6243bba7
      Sebastian Graf authored
      This is mostly for congruence with 'subWordC#' and '{add,sub}IntC#'.
      I found 'plusWord2#' while implementing this, which both lacks
      documentation and has a slightly different specification than
      'addWordC#', which means the generic implementation is unnecessarily
      While I was at it, I also added lacking meta-information on PrimOps
      and refactored 'subWordC#'s generic implementation to be branchless.
      Reviewers: bgamari, simonmar, jrtc27, dfeuer
      Reviewed By: bgamari, dfeuer
      Subscribers: dfeuer, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4592
  3. 19 Apr, 2018 1 commit
  4. 13 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Bump version numbers: base-, integer-gmp- · c4814ab6
      Ryan Scott authored
      This takes care of bumping the `base` and `integer-gmp`
      minor version numbers in anticipation of a GHC 8.4.2 release.
      While I was in town, I also filled in a `@since TODO` Haddock
      annotation for `powModSecInteger` in `integer-gmp` with
      ``, and updated the changelog accordingly.
      Test Plan: ./validate
      Reviewers: hvr, goldfire, bgamari
      Reviewed By: bgamari
      Subscribers: thomie, carter
      GHC Trac Issues: #15025
      Differential Revision: https://phabricator.haskell.org/D4586
  5. 08 Nov, 2017 1 commit
    • Simon Peyton Jones's avatar
      Minimise provided dictionaries in pattern synonyms · 2c2f3cea
      Simon Peyton Jones authored
      Trac #14394 showed that it's possible to get redundant
      constraints in the inferred provided constraints of a pattern
      synonym.  This patch removes the redundancy with mkMinimalBySCs.
      To do this I had to generalise the type of mkMinimalBySCs slightly.
      And, to reduce confusing reversal, I made it stable: it now returns
      its result in the same order as its input.  That led to a raft of
      error message wibbles, mostly for the better.
  6. 27 Oct, 2017 1 commit
    • Simon Marlow's avatar
      ApplicativeDo: handle BodyStmt (#12143) · 41f90559
      Simon Marlow authored
      It's simple to treat BodyStmt just like a BindStmt with a wildcard
      pattern, which is enough to fix #12143 without going all the way to
      using `<*` and `*>` (#10892).
      Test Plan:
      * new test cases in `ado004.hs`
      * validate
      Reviewers: niteria, simonpj, bgamari, austin, erikd
      Subscribers: rwbarton, thomie
      GHC Trac Issues: #12143
      Differential Revision: https://phabricator.haskell.org/D4128
  7. 16 Oct, 2017 1 commit
  8. 21 Sep, 2017 1 commit
  9. 23 Jul, 2017 1 commit
  10. 10 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix TcSimplify.decideQuantification for kind variables · 7e96526a
      Simon Peyton Jones authored
      TcSimplify.decideQuantification was doing the Wrong Thing when
      "growing" the type variables to quantify over. We were trying to do
      this on a tyvar set where we'd split off the dependent type varaibles;
      and we just got it wrong.  A kind variable wasn't being generalised
      properly, with confusing knock on consequences.
      All this led to Trac #13371 and Trac #13393.
      This commit tidies it all up:
      * The type TcDepVars is renamed as CandidateQTvs;
        and splitDepVarsOfType to candidateQTyVarsOfType
      * The code in TcSimplify.decideQuantification is simpler.
        It no longer does the tricky "grow" stuff over TcDepVars.
        Instead it use ordinary VarSets (thereby eliminating the
        nasty growThetaTyVarsDSet) and uses that to filter the
        result of candidateQTyVarsOfType.
      * I documented that candidateQTyVarsOfType returns the type
        variables in a good order in which to quantify, and rewrote
        it to use an accumulator pattern, so that we would predicatably
        get left-to-right ordering.
      In doing all this I also made UniqDFM behave a little more nicely:
      * When inserting an element that is there already, keep the old tag,
        while still overwriting with the new value.
      * This means that when doing udfmToList we get back elements in the
        order they were originally inserted, rather than in reverse order.
      It's not a big deal, but in a subsequent commit I use it to improve
      the order of type variables in inferred types.
      All this led to a lot of error message wibbles:
       - changing the order of quantified variables
       - changing the order in which instances are listed in GHCi
       - changing the tidying of variables in typechecker erors
      There's a submodule update for 'array' because one of its tests
      has an error-message change.
      I may not have associated all of them with the correct commit.
  11. 15 Dec, 2016 1 commit
  12. 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
  13. 14 Jul, 2016 1 commit
  14. 20 Jun, 2016 1 commit
  15. 04 May, 2016 1 commit
    • niteria's avatar
      Kill non-deterministic foldUFM in TrieMap and TcAppMap · ad4392c1
      niteria authored
      foldUFM introduces unnecessary non-determinism that actually
      leads to different generated code as explained in
      Note [TrieMap determinism].
      As we're switching from UniqFM to UniqDFM here you might be
      concerned about performance. There's nothing that ./validate
      detects. nofib reports no change in Compile Allocations, but
      Compile Time got better on some tests and worse on some,
      yielding this summary:
              -1 s.d.                -----            -3.8%
              +1 s.d.                -----            +5.4%
              Average                -----            +0.7%
      This is not a fair comparison as the order of Uniques
      changes what GHC is actually doing. One benefit from making
      this deterministic is also that it will make the
      performance results more stable.
      Full nofib results: P108
      Test Plan: ./validate, nofib
      Reviewers: goldfire, simonpj, simonmar, austin, bgamari
      Reviewed By: simonpj
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2169
      GHC Trac Issues: #4012
  16. 26 Apr, 2016 1 commit
    • niteria's avatar
      Kill varSetElemsWellScoped in quantifyTyVars · c9bcaf31
      niteria authored
      varSetElemsWellScoped introduces unnecessary non-determinism in
      inferred type signatures.
      Removing this instance required changing the representation of
      TcDepVars to use deterministic sets.
      This is the last occurence of varSetElemsWellScoped, allowing me to
      finally remove it.
      Test Plan:
      I will update the expected outputs when commiting, some reordering
      of type variables in types is expected.
      Reviewers: goldfire, simonpj, austin, bgamari
      Reviewed By: simonpj
      Subscribers: thomie, simonmar
      Differential Revision: https://phabricator.haskell.org/D2135
      GHC Trac Issues: #4012
  17. 11 Mar, 2016 1 commit
    • Simon Marlow's avatar
      Add -foptimal-applicative-do · 2f45cf3f
      Simon Marlow authored
      The algorithm for ApplicativeDo rearrangement is based on a heuristic
      that runs in O(n^2).  This patch adds the optimal algorithm, which is
      O(n^3), selected by a flag (-foptimal-applicative-do).  It finds better
      solutions in a small number of cases (about 2% of the cases where
      ApplicativeDo makes a difference), but it can be very slow for large do
      expressions.  I'm mainly adding it for experimental reasons.
      ToDo: user guide docs
      Test Plan: validate
      Reviewers: simonpj, bgamari, austin, niteria, erikd
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1969
  18. 27 Jan, 2016 1 commit
    • 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.
  19. 15 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Allow recursive (undecidable) superclasses · 6eabb6dd
      Simon Peyton Jones authored
      This patch fulfils the request in Trac #11067, #10318, and #10592,
      by lifting the conservative restrictions on superclass constraints.
      These restrictions are there (and have been since Haskell was born) to
      ensure that the transitive superclasses of a class constraint is a finite
      set.  However (a) this restriction is conservative, and can be annoying
      when there really is no recursion, and (b) sometimes genuinely recursive
      superclasses are useful (see the tickets).
      Dimitrios and I worked out that there is actually a relatively simple way
      to do the job. It’s described in some detail in
         Note [The superclass story] in TcCanonical
         Note [Expanding superclasses] in TcType
      In brief, the idea is to expand superclasses only finitely, but to
      iterate (using a loop that already existed) if there are more
      superclasses to explore.
      Other small things
      - I improved grouping of error messages a bit in TcErrors
      - I re-centred the haddock.compiler test, which was at 9.8%
        above the norm, and which this patch pushed slightly over
  20. 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.
  21. 01 Nov, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Bump ghc-prim version to (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-,ghc-prim-,g $(git grep -Fl 'ghc-prim-')
      was performed.
    • Herbert Valerio Riedel's avatar
      Bump `base` version to (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-,base-,g $(git grep -Fl 'base-')
      because it turns out the testsuite is still sensitive to package version
  22. 17 Sep, 2015 1 commit