1. 06 Nov, 2013 2 commits
    • Simon Peyton Jones's avatar
      Improve printing of errors when the tycons look the same · 2403fa10
      Simon Peyton Jones authored
      See Trac #8278.  Example new message:
      
          Couldn't match expected type ‛T8278a.Maybe’
                      with actual type ‛Maybe a0’
          NB: ‛T8278a.Maybe’ is defined in ‛T8278a’
              ‛Maybe’ is defined in ‛Data.Maybe’ in package ‛base’
          In the first argument of ‛f’, namely ‛Nothing’
      
      The "NB" is the new bit
      2403fa10
    • Simon Peyton Jones's avatar
      Refactor the constraint solver (again!) · 06aac68d
      Simon Peyton Jones authored
      There are three core changes here:
      
      a) In the constraint-solver pipeline.
         Given a work-item 'wi', the old scheme was:
            let relevant = getRelevantInerts wi
            interact 'wi' with each constraint in 'relevant'
         Bu now we have a single step
            interact 'wi' with the inert-set
      
         This turns out to avoid duplication, between getRelevantInerts
         (which needs to know which are relevant) and the interact step.
         Simpler, cleaner.
      
         This in turn made it sensible to combine the 'spontaneous solve'
         stage into the 'interact with inerts' stage.
      
      b) Wanteds are no longer used to rewrite wanteds.  See Trac #8450.
         This in turn means that the inert set may have
           - many CFunEqCans with the same LHS
           - many CTyEqCans  with the same LHS
         Hence the EqualCtList in teh domain of inert_eqs and inert_funeqs
      
      c) Some refactoring of the representation of the inert set,
         Notably inert_dicts and inert_funeqs are indexed by Class and TyCon
         respectively, so we can easily get all the constraints relevant to
         that class or tycon
      
      There are many knock on effects!  This started as a small job but I
      ended up doing qite a lot.  Some error messages in the test suite
      really did improve as a result of (b)
      06aac68d
  2. 01 Oct, 2013 1 commit
  3. 14 Sep, 2013 1 commit
  4. 13 Sep, 2013 1 commit
  5. 10 Sep, 2013 1 commit
    • Simon Peyton Jones's avatar
      Improve error reporting for "relevant bindings" again (Trac #8233) · 9039108b
      Simon Peyton Jones authored
      This patch makes a number of related improvements:
      
      * Displays relevant bindings in innermost-first order.
        The inner ones are closer to the error.
      
      * Does not display syntactically top-level bindings,
        unless you say -fno-max-relevant-bindings.
        This is what Trac #8233 was mainly about
      
      * Makes the TopLevelFlag in a TcIdBinder really mean
        "syntactically top level".  It was a bit vague before.
      
      There was some associated simplification, because we no longer
      need to pas a TopLevelFlag to tcMonoBinds and friends.
      9039108b
  6. 29 Aug, 2013 1 commit
  7. 23 Apr, 2013 1 commit
  8. 22 Apr, 2013 1 commit
    • Simon Peyton Jones's avatar
      Further wibbbling to type error message reporting · 2a7f4de3
      Simon Peyton Jones authored
      * We now never report derived-constraint type errors, even
        in the "insolubles".  See Note [Insoluble derived constraints]
        in TcRnTypes.
      
      * The cec_suppress mechanism in TcErrors is refactored a bit so that:
         - We suppress *all* errors in unreachable code (they can be jolly
           confusing)
         - We no longer suppress *all* non-insoluble errors if there are *any
           insolubles anywhere.  Instead we are a bit more refined.
        See Note [Suppressing error messages] in TcErrors
      2a7f4de3
  9. 21 Apr, 2013 1 commit
  10. 14 Feb, 2013 1 commit
  11. 30 Jan, 2013 2 commits
  12. 08 Jan, 2013 1 commit
    • Simon Peyton Jones's avatar
      Re-engineer the ambiguity test for user type signatures · 97db0edc
      Simon Peyton Jones authored
      Two main changes. First, re-engineer the ambiguity test.  Previously
      TcMType.checkAmbiguity used a rather syntactic test to detect some
      types that are certainly ambiguous.  But a much easier test is available,
      and it is used for inferred types in TcBinds. Namely
          <type> is ambiguous
      iff
         <type> `TcUnify.isSubType` <type>
      fails to hold, where "isSubType" means "is provably more polymorphic than".
      Example:
            C a => Int
      is ambiguous, because isSubType instantiates the (C a => Int)
      to (C alpha => Int) and then tries to deduce (C alpha) from (C a). This is
      Martin Sulzmann's definition of ambiguity.  (Defn 10 of "Understanding
      functional dependencies via constraint handling rules", JFP.)
      
      This change is neat, reduces code, and correctly rejects more programs.
      However is *is* just possible to have a useful program that would be
      rejected. For example
                class C a b
                f :: C Int b => Int -> Int
      Here 'f' would be rejected as having an ambiguous type. But it is
      just possible that, at a *call* site there might be an instance
      declaration  instance C Int b, which does not constrain 'b' at all.
      This is pretty strange -- why is 'b' overloaded at all? -- but it's
      possible, so I also added a flag -XAllowAmbiguousTypes that simply
      removes the ambiguity check.  Let's see if anyone cares.  Meanwhile
      the earlier error report will be useful for everyone else.
      
      A handful of regression tests had to be adjusted as a result, because
      they used ambiguous types, somewhat accidentally.
      
      Second, split TcMType (already too large) into two
      
        * TcMType: a low-level module dealing with monadic operations like
          zonking, creating new evidence variables, etc
      
        * TcValidity: a brand-new higher-level module dealing with
          validity checking for types: checkValidType, checkValidInstance,
          checkFamInstPats etc
      
      Apart from the fact that TcMType was too big, this allows TcValidity
      to import TcUnify(tcSubType) without causing a loop.
      97db0edc
  13. 31 Oct, 2012 2 commits
    • Simon Peyton Jones's avatar
      Wibble to recent changes to TcErrors · 2677e428
      Simon Peyton Jones authored
      2677e428
    • Simon Peyton Jones's avatar
      Do not instantiate unification variables with polytypes · 10f83429
      Simon Peyton Jones authored
      Without -XImpredicativeTypes, the typing rules say that a function
      should be instantiated only at a *monotype*.  In implementation terms,
      that means that a unification variable should not unify with a type
      involving foralls.  But we were not enforcing that rule, and that
      gave rise to some confusing error messages, such as
        Trac #7264, #6069
      
      This patch adds the test for foralls.  There are consequences
      
       * I put the test in occurCheckExpand, since that is where we see if a
         type can unify with a given unification variable.  So
         occurCheckExpand has to get DynFlags, so it can test for
         -XImpredicativeTypes
      
       * We want this to work
            foo :: (forall a. a -> a) -> Int
            foo = error "foo"
         But that means instantiating error at a polytype!  But error is special
         already because you can instantiate it at an unboxed type like Int#.
         So I extended the specialness to allow type variables of openTypeKind
         to unify with polytypes, regardless of -XImpredicativeTypes.
      
         Conveniently, this works in TcUnify.matchExpectedFunTys, which generates
         unification variable for the function arguments, which can be polymorphic.
      
       * GHC has a special typing rule for ($) (see Note [Typing rule
         for ($)] in TcExpr).  It unifies the argument and result with a
         unification variable to exclude unboxed types -- but that means I
         now need a kind of unificatdion variable that *can* unify with a
         polytype.
      
         So for this sole case I added PolyTv to the data type TcType.MetaInfo.
         I suspect we'll find mor uses for this, and the changes are tiny,
         but it still feel a bit of a hack.  Well the special rule for ($)
         is a hack!
      
      There were some consequential changes in error reporting (TcErrors).
      10f83429
  14. 19 Oct, 2012 2 commits
  15. 16 Oct, 2012 1 commit
    • ian@well-typed.com's avatar
      Some alpha renaming · cd33eefd
      ian@well-typed.com authored
      Mostly d -> g (matching DynFlag -> GeneralFlag).
      Also renamed if* to when*, matching the Haskell if/when names
      cd33eefd
  16. 15 Oct, 2012 1 commit
  17. 04 Oct, 2012 1 commit
  18. 03 Oct, 2012 1 commit
  19. 28 Sep, 2012 1 commit
    • Simon Peyton Jones's avatar
      Refactor the handling of kind errors · 9a058b17
      Simon Peyton Jones authored
      * Treat kind-equality constraints as *derived* equalities,
        with no evidence.  That is really what they are at the moment.
      
      * Get rid of EvKindCast and friends.
      
      * Postpone kind errors properly to the constraint solver
        (lots of small knock-on effects)
      
      I moved SwapFlag to BasicTypes as well
      9a058b17
  20. 21 Sep, 2012 1 commit
  21. 17 Sep, 2012 3 commits
    • Simon Peyton Jones's avatar
      Remove cc_ty from CIrredCan and cc_hole_ty from CHoleCan · 1a6ab644
      Simon Peyton Jones authored
      A simple refactoring with no complicated fiddling.
      1a6ab644
    • Simon Peyton Jones's avatar
      Another refactoring of constraints · d30b9cf4
      Simon Peyton Jones authored
      1. Rejig CtLoc
         * CtLoc is now *not* parameterised (much simpler)
         * CtLoc includes the "depth" of the constraint
         * CtLoc includes the TcLclEnv at the birthplace
           That gives (a) the SrcSpan, (b) the [ErrCtxt]
           (c) the [TcIdBinder]
         * The CtLoc of a constraint is no longer in its CtEvidence
         * Where we passed 'depth' before, now we pass CtLoc
      
      2. Some significant refactoring in TcErrors
         * Get rid of cec_extra
         * Traverse every constraint, so that we can be
           sure to generate bindings where necessary.
           (This was really a lurking bug before.)
      
      3. Merge zonking into TcCanonical.  This turned out to be
         almost trivial; just a small change to TcCanonical.flattenTyVar.
      
         The nice consequence is that we don't need to zonk a constraint
         before solving it; instead it gets zonked "on the fly" as it were.
      d30b9cf4
    • Simon Peyton Jones's avatar
      Add type "holes", enabled by -XTypeHoles, Trac #5910 · 8a9a7a8c
      Simon Peyton Jones authored
      This single commit combines a lot of work done by
      Thijs Alkemade <thijsalkemade@gmail.com>, plus a slew
      of subsequent refactoring by Simon PJ.
      
      The basic idea is
      * Add a new expression form "_", a hole, standing for a not-yet-written expression
      * Give a useful error message that
         (a) gives the type of the hole
         (b) gives the types of some enclosing value bindings that
             mention the hole
      
      Driven by this goal I did a LOT of refactoring in TcErrors, which in turn
      allows us to report enclosing value bindings for other errors, not just
      holes.  (Thijs rightly did not attempt this!)
      
      The major data type change is a new form of constraint
        data Ct = ...
          	  | CHoleCan {
          	      cc_ev       :: CtEvidence,
          	      cc_hole_ty  :: TcTauType,
          	      cc_depth    :: SubGoalDepth }
      
      I'm still in two minds about whether this is the best plan. Another
      possibility would be to have a predicate type for holes, somthing like
         class Hole a where
           holeValue :: a
      
      It works the way it is, but there are some annoying special cases for
      CHoleCan (just grep for "CHoleCan").
      8a9a7a8c
  22. 06 Sep, 2012 1 commit
  23. 01 Sep, 2012 1 commit
    • Simon Peyton Jones's avatar
      A bunch more simplification and refactoring to the constraint solver · fe6ddf00
      Simon Peyton Jones authored
      * Instead of Untouchables being a [Unique], it is simply an Int
        indicating the depth of nesting.  This works fine now that
        floatEqualities is promoting the floated unification variables
        to the outer level
      
      * Remove the inert_tv_eqs (InScopeSet) from InertCans.  It wasn't
        being used.  See Note [Shadowing in a constraint] in TcRnTypes
      
      * Rename inert_frozen to inert_insols
      
      * Some simple refactoring in
           TcErrors.reportFlatsAndInsols
           TcInteract.kickOutRewritable
           TsSimplify.floatEqualities
      fe6ddf00
  24. 30 Aug, 2012 1 commit
    • Simon Peyton Jones's avatar
      A raft more changes, · 2b69233d
      Simon Peyton Jones authored
       * simplifying and tidying up canonicalisation,
       * removing the flat cache altogether
       * making the FunEq worklist into a deque
      2b69233d
  25. 29 Aug, 2012 1 commit
  26. 28 Aug, 2012 1 commit
  27. 23 Jul, 2012 1 commit
    • Simon Peyton Jones's avatar
      Numerous small changes to the constraint solver · 9c0a6bbb
      Simon Peyton Jones authored
      The main thing is that we now keep unsolved Derived constraints in the
      wc_flats of a WantedConstraints, rather than discarding them each time.
      This actually fixes a poential (admittedly obscure) bug, when we currently
      discard a superclass constraint, and may never re-generate it, and may
      thereby miss a functional dependency.
      
      Instead, reportErrors filters out Derived constraints that we don't want
      to report.
      
      The other changes are all small refactorings following our walk-through.
      9c0a6bbb
  28. 10 Jul, 2012 1 commit
  29. 27 Jun, 2012 1 commit
    • Simon Peyton Jones's avatar
      Add silent superclass parameters (again) · aa1e0976
      Simon Peyton Jones authored
      Silent superclass parameters solve the problem that
      the superclasses of a dicionary construction can easily
      turn out to be (wrongly) bottom.  The problem and solution
      are described in
         Note [Silent superclass arguments] in TcInstDcls
      
      I first implemented this fix (with Dimitrios) in Dec 2010, but removed
      it again in Jun 2011 becuase we thought it wasn't necessary any
      more. (The reason we thought it wasn't necessary is that we'd stopped
      generating derived superclass constraints for *wanteds*.  But we were
      wrong; that didn't solve the superclass-loop problem.)
      
      So we have to re-implement it.  It's not hard.  Main features:
      
        * The IdDetails for a DFunId says how many silent arguments it has
      
        * A DFunUnfolding describes which dictionary args are
          just parameters (DFunLamArg) and which are a function to apply
          to the parameters (DFunPolyArg).  This adds the DFunArg type
          to CoreSyn
      
        * Consequential changes to IfaceSyn.  (Binary hi file format changes
          slightly.)
      
        * TcInstDcls changes to generate the right dfuns
      
        * CoreSubst.exprIsConApp_maybe handles the new DFunUnfolding
      
      The thing taht is *not* done yet is to alter the vectoriser to
      pass the relevant extra argument when building a PA dictionary.
      aa1e0976
  30. 13 Jun, 2012 1 commit
    • Simon Peyton Jones's avatar
      Simplify the implementation of Implicit Parameters · 5a8ac0f8
      Simon Peyton Jones authored
      This patch re-implements implicit parameters via a class
      with a functional dependency:
      
          class IP (n::Symbol) a | n -> a where
            ip :: a
      
      This definition is in the library module GHC.IP. Notice
      how it use a type-literal, so we can have constraints like
         IP "x" Int
      Now all the functional dependency machinery works right to make
      implicit parameters behave as they should.
      
      Much special-case processing for implicit parameters can be removed
      entirely. One particularly nice thing is not having a dedicated
      "original-name cache" for implicit parameters (the nsNames field of
      NameCache).  But many other cases disappear:
      
        * BasicTypes.IPName
        * IPTyCon constructor in Tycon.TyCon
        * CIPCan constructor  in TcRnTypes.Ct
        * IPPred constructor  in Types.PredTree
      
      Implicit parameters remain special in a few ways:
      
       * Special syntax.  Eg the constraint (IP "x" Int) is parsed
         and printed as (?x::Int).  And we still have local bindings
         for implicit parameters, and occurrences thereof.
      
       * A implicit-parameter binding  (let ?x = True in e) amounts
         to a local instance declaration, which we have not had before.
         It just generates an implication contraint (easy), but when
         going under it we must purge any existing bindings for
         ?x in the inert set.  See Note [Shadowing of Implicit Parameters]
         in TcSimplify
      
       * TcMType.sizePred classifies implicit parameter constraints as size-0,
         as before the change
      
      There are accompanying patches to libraries 'base' and 'haddock'
      
      All the work was done by Iavor Diatchki
      5a8ac0f8
  31. 12 Jun, 2012 1 commit
  32. 25 May, 2012 1 commit
  33. 07 May, 2012 1 commit
    • Simon Peyton Jones's avatar
      Yet another major refactoring of the constraint solver · dd7522c3
      Simon Peyton Jones authored
      This is the result of Simon and Dimitrios doing a code walk through.
      There is no change in behaviour, but the structure is much better.
      Main changes:
      
      * Given constraints contain an EvTerm not an EvVar
      
      * Correspondingly, TcEvidence is a recursive types that uses
        EvTerms rather than EvVars
      
      * Rename CtFlavor to CtEvidence
      
      * Every CtEvidence has a ctev_pred field.  And use record fields
        consistently for CtEvidence
      
      * The solved-constraint fields of InertSet (namely inert_solved and
        inert_solved_funeqs) contain CtEvidence, not Ct
      
      There is a long cascade of follow-on changes.
      dd7522c3
  34. 01 May, 2012 1 commit
    • Simon Peyton Jones's avatar
      Tidy up a remaining glitch in unification · 67c793a3
      Simon Peyton Jones authored
      There was one place, in type checking parallel list comprehensions
      where we were unifying types, but had no convenient way to use the
      resulting coercion; instead we just checked that it was Refl.  This
      was Wrong Wrong; it might fail unpredicably in a GADT-like situation,
      and it led to extra error-generation code used only in this one place.
      
      This patch tidies it all up, by moving the 'return' method from the
      *comprehension* to the ParStmtBlock. The latter is a new data type,
      now used for each sub-chunk of a parallel list comprehension.
      
      Because of the data type change, quite a few modules are touched,
      but only in a fairly trivial way. The real changes are in TcMatches
      (and corresponding desugaring); plus deleting code from TcUnify.
      
      This patch also fixes the pretty-printing bug in Trac #6060
      67c793a3