1. 14 Mar, 2014 1 commit
  2. 13 Feb, 2014 1 commit
  3. 09 Jan, 2014 1 commit
  4. 04 Dec, 2013 1 commit
  5. 03 Dec, 2013 1 commit
  6. 02 Dec, 2013 1 commit
  7. 22 Nov, 2013 6 commits
  8. 20 Nov, 2013 1 commit
    • Joachim Breitner's avatar
      Make Coercible higher-kinded · 976a1087
      Joachim Breitner authored
      This implements #8541. The changes are fully straight forward and work
      nicely for the examples from the ticket; this is mostly due to the
      existing code not checking for saturation and kindness.
      976a1087
  9. 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
  10. 01 Oct, 2013 1 commit
  11. 14 Sep, 2013 1 commit
  12. 13 Sep, 2013 1 commit
  13. 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
  14. 29 Aug, 2013 1 commit
  15. 23 Apr, 2013 1 commit
  16. 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
  17. 21 Apr, 2013 1 commit
  18. 14 Feb, 2013 1 commit
  19. 30 Jan, 2013 2 commits
  20. 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
  21. 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
  22. 19 Oct, 2012 2 commits
  23. 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
  24. 15 Oct, 2012 1 commit
  25. 04 Oct, 2012 1 commit
  26. 03 Oct, 2012 1 commit
  27. 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
  28. 21 Sep, 2012 1 commit
  29. 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