1. 15 Mar, 2019 1 commit
  2. 03 Dec, 2018 1 commit
    • Simon Peyton Jones's avatar
      Introduce tcTypeKind, and use it · 03d48526
      Simon Peyton Jones authored
      In the type checker Constraint and * are distinct; and the function
      that takes the kind of a type should respect that distinction
      (Trac #15971).
      This patch implements the change:
      * Introduce Type.tcTypeKind, and use it throughout the type
        inference engine
      * Add new Note [Kinding rules for types] for the kinding
        rules, especially for foralls.
      * Redefine
          isPredTy ty = tcIsConstraintKind (tcTypeKind ty)
        (it had a much more complicated definition before)
      Some miscellaneous refactoring
      * Get rid of TyCoRep.isTYPE, Kind.isTYPEApp,
        in favour of TyCoRep.kindRep, kindRep_maybe
      * Rename Type.getRuntimeRepFromKind_maybe
        to getRuntimeRep_maybe
      I did some spot-checks on compiler perf, and it really doesn't
      budge (as expected).
  3. 22 Nov, 2018 1 commit
    • David Eichmann's avatar
      Fix unused-import warnings · 6353efc7
      David Eichmann authored and Ben Gamari's avatar Ben Gamari committed
      This patch fixes a fairly long-standing bug (dating back to 2015) in
      RdrName.bestImport, namely
         commit 9376249b
         Author: Simon Peyton Jones <simonpj@microsoft.com>
         Date:   Wed Oct 28 17:16:55 2015 +0000
         Fix unused-import stuff in a better way
      In that patch got the sense of the comparison back to front, and
      thereby failed to implement the unused-import rules described in
        Note [Choosing the best import declaration] in RdrName
      This led to Trac #13064 and #15393
      Fixing this bug revealed a bunch of unused imports in libraries;
      the ones in the GHC repo are part of this commit.
      The two important changes are
      * Fix the bug in bestImport
      * Modified the rules by adding (a) in
           Note [Choosing the best import declaration] in RdrName
        Reason: the previosu rules made Trac #5211 go bad again.  And
        the new rule (a) makes sense to me.
      In unravalling this I also ended up doing a few other things
      * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the
        things that are used, rather than [AvailInfo]. This is simpler
        and more direct.
      * Rename greParentName to greParent_maybe, to follow GHC
        naming conventions
      * Delete dead code RdrName.greUsedRdrName
      Bumps a few submodules.
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5312
  4. 25 Oct, 2018 1 commit
  5. 24 Oct, 2018 1 commit
    • Simon Peyton Jones's avatar
      Refactor the treatment of predicate types · 0faf7fd3
      Simon Peyton Jones authored
      Trac #15648 showed that GHC was a bit confused about the
      difference between the types for
      * Predicates
      * Coercions
      * Evidence (in the typechecker constraint solver)
      This patch cleans it up. See especially Type.hs
      Note [Types for coercions, predicates, and evidence]
      Particular changes
      * Coercion types (a ~# b) and (a ~#R b) are not predicate types
        (so isPredTy reports False for them) and are not implicitly
        instantiated by the type checker.  This is a real change, but
        it consistently reflects that fact that (~#) and (~R#) really
        are different from predicates.
      * isCoercionType is renamed to isCoVarType
      * During type inference, simplifyInfer, we do /not/ want to infer
        a constraint (a ~# b), because that is no longer a predicate type.
        So we 'lift' it to (a ~ b). See TcType
        Note [Lift equality constaints when quantifying]
      * During type inference for pattern synonyms, we need to 'lift'
        provided constraints of type (a ~# b) to (a ~ b).  See
        Note [Equality evidence in pattern synonyms] in PatSyn
      * But what about (forall a. Eq a => a ~# b)? Is that a
        predicate type?  No -- it does not have kind Constraint.
        Is it an evidence type?  Perhaps, but awkwardly so.
        In the end I decided NOT to make it an evidence type,
        and to ensure the the type inference engine never
        meets it.  This made me /simplify/ the code in
        TcCanonical.makeSuperClasses; see TcCanonical
        Note [Equality superclasses in quantified constraints]
        Instead I moved the special treatment for primitive
        equality to TcInteract.doTopReactOther.  See TcInteract
        Note [Looking up primitive equalities in quantified constraints]
        Also see Note [Evidence for quantified constraints] in Type.
        All this means I can have
           isEvVarType ty = isCoVarType ty || isPredTy ty
        which is nice.
      All in all, rather a lot of work for a small refactoring,
      but I think it's a real improvement.
  6. 13 Sep, 2018 1 commit
    • Simon Peyton Jones's avatar
      Allow (~) in the head of a quantified constraints · bd76875a
      Simon Peyton Jones authored
      Since the introduction of quantified constraints, GHC has rejected
      a quantified constraint with (~) in the head, thus
        f :: (forall a. blah => a ~ ty) => stuff
      I am frankly dubious that this is ever useful.  But /is/ necessary for
      Coercible (representation equality version of (~)) and it does no harm
      to allow it for (~) as well.  Plus, our users are asking for it
      (Trac #15359, #15625).
      It was really only excluded by accident, so
      this patch lifts the restriction. See TcCanonical
      Note [Equality superclasses in quantified constraints]
      There are a number of wrinkles:
      * If the context of the quantified constraint is empty, we
        can get trouble when we get down to unboxed equality (a ~# b)
        or (a ~R# b), as Trac #15625 showed. This is even more of
        a corner case, but it produced an outright crash, so I elaborated
        the superclass machinery in TcCanonical.makeStrictSuperClasses
        to add a void argument in this case.  See
        Note [Equality superclasses in quantified constraints]
      * The restriction on (~) was in TcValidity.checkValidInstHead.
        In lifting the restriction I discovered an old special case for
        (~), namely
            | clas_nm `elem` [ heqTyConName, eqTyConName]
            , nameModule clas_nm /= this_mod
        This was (solely) to support the strange instance
            instance a ~~ b => a ~ b
        in Data.Type.Equality. But happily that is no longer
        with us, since
           commit f265008f
           Refactor (~) to reduce the suerpclass stack
        So I removed the special case.
      * I found that the Core invariants on when we could have
             co = <expr>
        were entirely not written down. (Getting this wrong ws
        the proximate source of the crash in Trac #15625.  So
        - Documented them better in CoreSyn
            Note [CoreSyn type and coercion invariant],
        - Modified CoreOpt and CoreLint to match
        - Modified CoreUtils.bindNonRec to match
        - Made MkCore.mkCoreLet use bindNonRec, rather
          than duplicate its logic
        - Made Simplify.rebuildCase case-to-let respect
            Note [CoreSyn type and coercion invariant],
  7. 25 Jul, 2018 2 commits
    • Simon Peyton Jones's avatar
      tc-tracing only · a434bcbc
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Fix and document cloneWC · 857ef25e
      Simon Peyton Jones authored
      The cloneWC, cloneWanted, cloneImplication family are used by
        * TcHoleErrors
        * TcRule
      to clone the /bindings/ in a constraint, so that solving the
      constraint will not add bindings to the program. The idea is only
      to affect unifications.
      But I had it wrong -- I failed to clone the EvBindsVar of an
      implication.  That gave an assert failure, I think, as well as
      useless dead code.
      The fix is easy.  I'm not adding a test case.
      In the type 'TcEvidence.EvBindsVar', I also renamed the
      'NoEvBindsVar' constructor to 'CoEvBindsVar'.  It's not that we
      have /no/ evidence bindings, just that we can only have coercion
      bindings, done via HoleDest.
  8. 05 Jul, 2018 1 commit
    • Simon Peyton Jones's avatar
      Refactor validity checking for constraints · 45f44e2c
      Simon Peyton Jones authored
      There are several changes here.
      * TcInteract has gotten too big, so I moved all the class-instance
        matching out of TcInteract into a new module ClsInst. It parallels
        the FamInst module.
        The main export of ClsInst is matchGlobalInst.
        This now works in TcM not TcS.
      * A big reason to make matchGlobalInst work in TcM is that we can
        then use it from TcValidity.checkSimplifiableClassConstraint.
        That extends checkSimplifiableClassConstraint to work uniformly
        for built-in instances, which means that we now get a warning
        if we have givens (Typeable x, KnownNat n); see Trac #15322.
      * This change also made me refactor LookupInstResult, in particular
        by adding the InstanceWhat field.  I also changed the name of the
        type to ClsInstResult.
        Then instead of matchGlobalInst reporting a staging error (which is
        inappropriate for the call from TcValidity), we can do so in
      * In TcValidity, we now check quantified constraints for termination.
        For example, this signature should be rejected:
           f :: (forall a. Eq (m a) => Eq (m a)) => blah
        as discussed in Trac #15316.   The main change here is that
        TcValidity.check_pred_help now uses classifyPredType, and has a
        case for ForAllPred which it didn't before.
        This had knock-on refactoring effects in TcValidity.
  9. 04 Jul, 2018 1 commit
  10. 22 Jun, 2018 2 commits
    • Simon Peyton Jones's avatar
      Refactor try_solve_fromInstance in shortCutSolver · e0653697
      Simon Peyton Jones authored
      This patch just removes the CtLoc parameter from trySolveFromInstance,
      since it can just as easily (and more uniformly) be gotten from the
      CtEvidence it is trying to solve.
    • Simon Peyton Jones's avatar
      Instances in no-evidence implications · 32eb4199
      Simon Peyton Jones authored
      Trac #15290 showed that it's possible that we might attempt to use a
      quantified constraint to solve an equality in a situation where we
      don't have anywhere to put the evidence bindings.  This made GHC crash.
      This patch stops the crash, but still rejects the pogram.  See
      Note [Instances in no-evidence implications] in TcInteract.
      Finding this bug revealed another lurking bug:
      * An infelicity in the treatment of superclasses -- we were expanding
        them locally at the leaves, rather than at their binding site; see
        (3a) in Note [The superclass story].
        As a consequence, TcRnTypes.superclassesMightHelp must look inside
      In more detail:
      * Stop the crash, by making TcInteract.chooseInstance test for
        the no-evidence-bindings case.  In that case we simply don't
        use the instance.  This entailed a slight change to the type
        of chooseInstance.
      * Make TcSMonad.getPendingScDicts (now renamed getPendingGivenScs)
        return only Givens from the /current level/; and make
        TcRnTypes.superClassesMightHelp look inside implications.
      * Refactor the simpl_loop and superclass-expansion stuff in
        TcSimplify.  The logic is much easier to understand now, and
        has less duplication.
  11. 11 Jun, 2018 1 commit
  12. 04 Jun, 2018 1 commit
    • Simon Peyton Jones's avatar
      Implement QuantifiedConstraints · 7df58960
      Simon Peyton Jones authored and Ben Gamari's avatar Ben Gamari committed
      We have wanted quantified constraints for ages and, as I hoped,
      they proved remarkably simple to implement.   All the machinery was
      already in place.
      The main ticket is Trac #2893, but also relevant are
        #9123 (especially!  higher kinded roles)
      The wiki page is
      which in turn contains a link to the GHC Proposal where the change
      is specified.
      Here is the relevant Note:
      Note [Quantified constraints]
      The -XQuantifiedConstraints extension allows type-class contexts like
        data Rose f x = Rose x (f (Rose f x))
        instance (Eq a, forall b. Eq b => Eq (f b))
              => Eq (Rose f a)  where
          (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2
      Note the (forall b. Eq b => Eq (f b)) in the instance contexts.
      This quantified constraint is needed to solve the
       [W] (Eq (f (Rose f x)))
      constraint which arises form the (==) definition.
      Here are the moving parts
        * Language extension {-# LANGUAGE QuantifiedConstraints #-}
          and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension
        * A new form of evidence, EvDFun, that is used to discharge
          such wanted constraints
        * checkValidType gets some changes to accept forall-constraints
          only in the right places.
        * Type.PredTree gets a new constructor ForAllPred, and
          and classifyPredType analyses a PredType to decompose
          the new forall-constraints
        * Define a type TcRnTypes.QCInst, which holds a given
          quantified constraint in the inert set
        * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst],
          which holds all the Given forall-constraints.  In effect,
          such Given constraints are like local instance decls.
        * When trying to solve a class constraint, via
          TcInteract.matchInstEnv, use the InstEnv from inert_insts
          so that we include the local Given forall-constraints
          in the lookup.  (See TcSMonad.getInstEnvs.)
        * topReactionsStage calls doTopReactOther for CIrredCan and
          CTyEqCan, so they can try to react with any given
          quantified constraints (TcInteract.matchLocalInst)
        * TcCanonical.canForAll deals with solving a
          forall-constraint.  See
             Note [Solving a Wanted forall-constraint]
             Note [Solving a Wanted forall-constraint]
        * We augment the kick-out code to kick out an inert
          forall constraint if it can be rewritten by a new
          type equality; see TcSMonad.kick_out_rewritable
      Some other related refactoring
      * Move SCC on evidence bindings to post-desugaring, which fixed
        #14735, and is generally nicer anyway because we can use
        existing CoreSyn free-var functions.  (Quantified constraints
        made the free-vars of an ev-term a bit more complicated.)
      * In LookupInstResult, replace GenInst with OneInst and NotSure,
        using the latter for multiple matches and/or one or more
  13. 23 May, 2018 1 commit
    • Simon Peyton Jones's avatar
      Use dischargeFunEq consistently · a32c8f75
      Simon Peyton Jones authored
      Trac #15122 turned out to be interesting.
      * Were calling dischargeFmv in three places.
      * In all three cases we dealt with the Given case
      * In two of the three cases the Given code was right,
        (albeit duplicated).
      * In the third case (in TcCanonical.canCFunEqCan), we had
           ; case flav of
               Given -> return () -- nothing more to do.
        which was utterly wrong.
      The solution is easy: move the Given-case handling into
      dischargeFmv (now reenamed dischargeFunEq), and delete it
      from the call sites.
      Result: less code, easier to understand (dischargeFunEq handles
      all three cases, not just two out of three), and Trac #15122 is fixed.
  14. 21 May, 2018 2 commits
    • Simon Peyton Jones's avatar
      Make dischargeFmv handle Deriveds · 57858fc8
      Simon Peyton Jones authored
      A Derived CFunEqCan does not "own" its FlatMetaTv (fmv), and should not
      update it.  But one caller (canCFunEqCan) was failing to satisfy the
      precondition to dischargeFmv, which led to a crash (Trac #15170).
      I fixed this by making dischargeFmv handle Deriveds (to avoid forcing
      each caller to do so separately).
      NB: this does not completely fix the original #15170 bug, but I'll
      explain that on the ticket.  The test case for this patch is actually
      the program in comment:1.
    • Simon Peyton Jones's avatar
      Do better sharing in the short-cut solver · f2ce86c2
      Simon Peyton Jones authored
      Trac #15164 showed that it sometimes really matters to share
      sub-proofs when solving constraints.  Without it, we can get
      exponentialy bad behaviour.
      Fortunately, it's easily solved.
      Note [Shortcut try_solve_from_instance] explains.
      I did some minor assocaited refactoring.
  15. 18 May, 2018 2 commits
    • Simon Peyton Jones's avatar
      Do not unify representational equalities · ae292c6d
      Simon Peyton Jones authored
      This patch is an easy fix to Trac #15144, which was caused
      by accidentally unifying a representational equality in the
      unflattener.  (The main code in TcInteract was always careful
      not to do so, but I'd missed the test in the unflattener.)
      See Note [Do not unify representational equalities]
      in TcInteract
    • Simon Peyton Jones's avatar
      Comments only · 797a4623
      Simon Peyton Jones authored
  16. 13 May, 2018 1 commit
  17. 01 Apr, 2018 1 commit
    • Richard Eisenberg's avatar
      Track type variable scope more carefully. · faec8d35
      Richard Eisenberg authored
      The main job of this commit is to track more accurately the scope
      of tyvars introduced by user-written foralls. For example, it would
      be to have something like this:
        forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool
      In that type, a's kind must be k, but k isn't in scope. We had a
      terrible way of doing this before (not worth repeating or describing
      here, but see the old tcImplicitTKBndrs and friends), but now
      we have a principled approach: make an Implication when kind-checking
      a forall. Doing so then hooks into the existing machinery for
      preventing skolem-escape, performing floating, etc. This also means
      that we bump the TcLevel whenever going into a forall.
      The new behavior is done in TcHsType.scopeTyVars, but see also
      TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
      rewriting. There are several Notes near there to guide you. Of
      particular interest there is that Implication constraints can now
      have skolems that are out of order; this situation is reported in
      A major consequence of this is a slightly tweaked process for type-
      checking type declarations. The new Note [Use SigTvs in kind-checking
      pass] in TcTyClsDecls lays it out.
      The error message for dependent/should_fail/TypeSkolEscape has become
      noticeably worse. However, this is because the code in TcErrors goes to
      some length to preserve pre-8.0 error messages for kind errors. It's time
      to rip off that plaster and get rid of much of the kind-error-specific
      error messages. I tried this, and doing so led to a lovely error message
      for TypeSkolEscape. So: I'm accepting the error message quality regression
      for now, but will open up a new ticket to fix it, along with a larger
      error-message improvement I've been pondering. This applies also to
      dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.
      Other minor changes:
       - isUnliftedTypeKind didn't look for tuples and sums. It does now.
       - check_type used check_arg_type on both sides of an AppTy. But the left
         side of an AppTy isn't an arg, and this was causing a bad error message.
         I've changed it to use check_type on the left-hand side.
       - Some refactoring around when we print (TYPE blah) in error messages.
         The changes decrease the times when we do so, to good effect.
         Of course, this is still all controlled by
      Fixes #14066 #14749
      Test cases: dependent/should_compile/{T14066a,T14749},
  18. 26 Mar, 2018 1 commit
    • Richard Eisenberg's avatar
      Fix #12919 by making the flattener homegeneous. · e3dbb44f
      Richard Eisenberg authored
      This changes a key invariant of the flattener. Previously,
      flattening a type meant flattening its kind as well. But now,
      flattening is always homogeneous -- that is, the kind of the
      flattened type is the same as the kind of the input type.
      This is achieved by various wizardry in the TcFlatten.flatten_many
      function, as described in Note [flatten_many].
      There are several knock-on effects, including some refactoring
      in the canonicalizer to take proper advantage of the flattener's
      changed behavior. In particular, the tyvar case of can_eq_nc' no
      longer needs to take casts into account.
      Another effect is that flattening a tyconapp might change it
      into a casted tyconapp. This might happen if the result kind
      of the tycon contains a variable, and that variable changes
      during flattening. Because the flattener is homogeneous, it tacks
      on a cast to keep the tyconapp kind the same. However, this
      is problematic when flattening CFunEqCans, which need to have
      an uncasted tyconapp on the LHS and must remain homogeneous.
      The solution is a more involved canCFunEqCan, described in
      Note [canCFunEqCan].
      This patch fixes #13643 (as tested in typecheck/should_compile/T13643)
      and the panic in typecheck/should_compile/T13822 (as reported in #14024).
      Actually, there were two bugs in T13822: the first was just some
      incorrect logic in tryFill (part of the unflattener) -- also fixed
      in this patch -- and the other was the main bug fixed in this ticket.
      The changes in this patch exposed a long-standing flaw in OptCoercion,
      in that breaking apart an AppCo sometimes has unexpected effects on
      kinds. See new Note [EtaAppCo] in OptCoercion, which explains the
      problem and fix.
      Also here is a reversion of the major change in
      09bf135a, affecting ctEvCoercion.
      It turns out that making the flattener homogeneous changes the
      invariants on the algorithm, making the change in that patch
      no longer necessary.
      This patch also fixes:
        #14038 (dependent/should_compile/T14038)
        #13910 (dependent/should_compile/T13910)
        #13938 (dependent/should_compile/T13938)
        #14441 (typecheck/should_compile/T14441)
        #14556 (dependent/should_compile/T14556)
        #14720 (dependent/should_compile/T14720)
        #14749 (typecheck/should_compile/T14749)
      Sadly, this patch negatively affects performance of type-family-
      heavy code. The following patch fixes these performance degradations.
      However, the performance fixes are somewhat invasive and so I've
      kept them as a separate patch, labeling this one as [skip ci] so
      that validation doesn't fail on the performance cases.
  19. 08 Feb, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix isDroppableCt (Trac #14763) · 6edafe3b
      Simon Peyton Jones authored
      When finishing up an implication constraint, it's a bit tricky to
      decide which Derived constraints to retain (for error reporting) and
      which to discard.  I got this wrong in commit
         (Remove wc_insol from WantedConstraints)
      The particular problem in Trac #14763 was that we were reporting as an
      error a fundep-generated constraint
        (ex ~ T)
      where 'ex' is an existentially-bound variable in a pattern match.
      But this isn't really an error at all.
      This patch fixes the problem. Indeed, since I had to understand
      this rather tricky code, I took the opportunity to clean it up
      and document better.  See
        isDroppableCt :: Ct -> Bool
      and Note [Dropping derived constraints]
      I also removed wl_deriv altogether from the WorkList data type.  It
      was there in the hope of gaining efficiency by not even processing
      lots of derived constraints, but it has turned out that most derived
      constraints (notably equalities) must be processed anyway; see
      Note [Prioritise equalities] in TcSMonad.
      The two are coupled because to decide which constraints to put in
      wl_deriv I was using another variant of isDroppableCt.  Now it's much
      simpler -- and perhaps even more efficient too.
  20. 07 Feb, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix solveOneFromTheOther for RecursiveSuperclasses · 65069806
      Simon Peyton Jones authored
      This patch fixes the redundant superclass expansion
      in Trac #14774.
      The main change is to fix TcInterac.solveOneFromTheOther, so
      that it does not prefer a work-item with a binding if that binding
      transitively depends on the inert item we are comparing it with.
      Explained in Note [Replacement vs keeping] in TcInert, esp
      item (c) of the "Constraints coming from the same level" part.
      To make this work I refactored out a new function
      TcEvidence.findNeededEvVars, which was previously buried
      inside TcSimplify.neededEvVars.
      I added quite a few more comments and signposts about superclass
  21. 31 Jan, 2018 1 commit
  22. 26 Jan, 2018 1 commit
    • Joachim Breitner's avatar
      Turn EvTerm (almost) into CoreExpr (#14691) · 0e022e56
      Joachim Breitner authored
      Ideally, I'd like to do
          type EvTerm = CoreExpr
      and the type checker builds the evidence terms as it goes. This failed,
      becuase the evidence for `Typeable` refers to local identifiers that are
      added *after* the typechecker solves constraints. Therefore, `EvTerm`
      stays a data type with two constructors: `EvExpr` for `CoreExpr`
      evidence, and `EvTypeable` for the others.
      Delted `Note [Memoising typeOf]`, its reference (and presumably
      relevance) was removed in 8fa4bf9a.
      Differential Revision: https://phabricator.haskell.org/D4341
  23. 21 Dec, 2017 2 commits
    • Simon Peyton Jones's avatar
      Refactor coercion holes · a492af06
      Simon Peyton Jones authored
      In fixing Trac #14584 I found that it would be /much/ more
      convenient if a "hole" in a coercion (much like a unification
      variable in a type) acutally had a CoVar associated with it
      rather than just a Unique.  Then I can ask what the free variables
      of a coercion is, and get a set of CoVars including those
      as-yet-un-filled in holes.
      Once that is done, it makes no sense to stuff coercion holes
      inside UnivCo.  They were there before so we could know the
      kind and role of a "hole" coercion, but once there is a CoVar
      we can get that info from the CoVar.  So I removed HoleProv
      from UnivCoProvenance and added HoleCo to Coercion.
      In summary:
      * Add HoleCo to Coercion and remove HoleProv from UnivCoProvanance
      * Similarly in IfaceCoercion
      * Make CoercionHole have a CoVar in it, not a Unique
      * Make tyCoVarsOfCo return the free coercion-hole variables
        as well as the ordinary free CoVars.  Similarly, remember
        to zonk the CoVar in a CoercionHole
      We could go further, and remove CoercionHole as a distinct type
      altogther, just collapsing it into HoleCo.  But I have not done
      that yet.
    • Simon Peyton Jones's avatar
      Simplify HsPatSynDetails · 584cbd4a
      Simon Peyton Jones authored
      This is a pure refactoring.  Use HsConDetails to implement
      HsPatSynDetails, instead of defining a whole new data type.
      Less code, fewer types, all good.
  24. 19 Dec, 2017 1 commit
  25. 08 Nov, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix another dark corner in the shortcut solver · 30058b0e
      Simon Peyton Jones authored
      The shortcut solver for type classes (Trac #12791) was eagerly
      solving a constaint from an OVERLAPPABLE instance. It happened
      to be the only one in scope, so it was unique, but since it's
      specfically flagged as overlappable it's really a bad idea to
      solve using it, rather than using the Given dictionary.
      This led to Trac #14434, a nasty and hard to identify bug.
  26. 30 Oct, 2017 1 commit
  27. 20 Oct, 2017 1 commit
    • Simon Peyton Jones's avatar
      Improve kick-out in the constraint solver · 3acd6164
      Simon Peyton Jones authored
      This patch was provoked by Trac #14363.  Turned out that we were
      kicking out too many constraints in TcSMonad.kickOutRewritable, and
      that mean that the work-list never became empty: infinite loop!
      That in turn made me look harder at the Main Theorem in
      Note [Extending the inert equalities].
      Main changes
      * Replace TcType.isTyVarExposed by TcType.isTyVarHead.  The
        over-agressive isTyVarExposed is what caused Trac #14363.
        See Note [K3: completeness of solving] in TcSMonad.
      * TcType.Make anyRewriteableTyVar role-aware.  In particular,
            a ~R ty
        cannot rewrite
            b ~R f a
        See Note [anyRewriteableTyVar must be role-aware].  That means
        it has to be given a role argument, which forces a little
        I think this change is fixing a bug that hasn't yet been reported.
        The actual reported bug is handled by the previous bullet.  But
        this change is definitely the Right Thing
      The main changes are in TcSMonad.kick_out_rewritable, and in TcType
      (isTyVarExposed ---> isTyVarHead).
      I did a little unforced refactoring:
       * Use the cc_eq_rel field of a CTyEqCan when it is available, rather
         than recomputing it.
       * Define eqCanRewrite :: EqRel -> EqRel -> EqRel, and use it, instead
         of duplicating its logic
  28. 18 Oct, 2017 1 commit
    • Simon Peyton Jones's avatar
      Better solving for representational equalities · 5a66d574
      Simon Peyton Jones authored
      This patch adds a bit of extra solving power for representational
      equality constraints to fix Trac #14333
      The main changes:
      * Fix a buglet in TcType.isInsolubleOccursCheck which wrongly
        reported a definite occurs-check error for (a ~R# b a)
      * Get rid of TcSMonad.emitInsolubles.  It had an ad-hoc duplicate-removal
        piece that is better handled in interactIrred, now that insolubles
        are Irreds.
        We need a little care to keep inert_count (which does not include
        insolubles) accurate.
      * Refactor TcInteract.solveOneFromTheOther, to return a much simpler
        type.  It was just over-complicated before.
      * Make TcInteract.interactIrred look for constraints that match
        either way around, in TcInteract.findMatchingIrreds
      This wasn't hard and it cleaned up quite a bit of code.
  29. 11 Oct, 2017 1 commit
    • Simon Peyton Jones's avatar
      Remove wc_insol from WantedConstraints · f20cf982
      Simon Peyton Jones authored
      This patch is a pure refactoring, which I've wanted to do for
      some time.  The main payload is
      * Remove the wc_insol field from WantedConstraints;
        instead put all the insolubles in wc_simple
      * Remove inert_insols from InertCans
        Instead put all the insolubles in inert_irreds
      * Add a cc_insol flag to CIrredCan, to record that
        the constraint is definitely insoluble
      * Quite a bit of code gets slightly simpler
      * Fewer concepts to keep separate
      * Insolubles don't happen at all in production code that is
        just being recompiled, so previously there was a lot of
        moving-about of empty sets
      A couple of error messages acutally improved.
  30. 03 Oct, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix bug in the short-cut solver · a8fde183
      Simon Peyton Jones authored
      Trac #13943 showed that the relatively-new short-cut solver
      for class constraints (aka -fsolve-constant-dicts) was wrong.
      In particular, see "Type families" under Note [Shortcut solving]
      in TcInteract.
      The short-cut solver recursively solves sub-goals, but it doesn't
      flatten type-family applications, and as a result it erroneously
      thought that C (F a) cannot possibly match (C 0), which is
      simply untrue.  That led to an inifinte loop in the short-cut
      The significant change is the one line
      +                 , all isTyFamFree preds  -- See "Type families" in
      +                                          -- Note [Shortcut solving]
      but, as ever, I do some other refactoring.  (E.g. I changed the
      name of the function to shortCutSolver rather than the more
      generic trySolveFromInstance.)
      I also made the short-cut solver respect the solver-depth limit,
      so that if this happens again it won't just produce an infinite
      A bit of other refactoring, notably moving isTyFamFree
      from TcValidity to TcType
  31. 27 Sep, 2017 1 commit
  32. 26 Sep, 2017 2 commits
  33. 25 Sep, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix solving of implicit parameter constraints · abed9bf5
      Simon Peyton Jones authored
      Trac #14218 showed that we were not solving implicit-parameter
      constraints correctly.  In particular,
      - A tuple constraint could "hide" an implicit-parameter wanted
        constraint, and that in turn could that we solved it from the
        wrong implicit-parameter binding.
      - As a special case the HasCallStack constraint (which is just
        short for (IP "callStack" CallStack), was getting mis-solved.
      The big change is to arrange that, in TcSMonad.findDict when looking
      for a dictionary, either when looking for a matching inert or solved
      dictionary, we fail for
        - Tuples that are hiding implicit parameters
          See Note [Tuples hiding implicit parameters]
        - HasCallStack constraints where we have not yet pushed
          on the call-site info
          See Note [Solving CallStack constraints]
      I also did a little refactoring
      * Move naturallyCoherentClass from Class to TcInteract, its sole
        use site.  Class.hs seems like the wrong place.  (And I also
        do not understand the reason that we need the eq/Coercible/
        Typable stuff in this predicate, but I'll tackle that separately.)
      * Move the code that pushes call-site info onto a call stack
        from the "interact" part to the "canonicalise" part of the solver.
  34. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored and Ben Gamari's avatar Ben Gamari committed
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      Reviewed By: bgamari
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      Differential Revision: https://phabricator.haskell.org/D3989