1. 14 Apr, 2014 1 commit
  2. 08 Apr, 2014 1 commit
    • Simon Peyton Jones's avatar
      Improve error reporting for untouchable type variables · 50bfd421
      Simon Peyton Jones authored
      This change adds a suggestion
          Possible fix: add a type signature for ‘f’
      when we have a GADT-style definition with a
      type we can't figure out.
      See Note [Suggest adding a type signature] in TcErrors.
      This initially came up in the discussion of Trac #8968.
  3. 14 Mar, 2014 1 commit
  4. 13 Feb, 2014 1 commit
  5. 09 Jan, 2014 1 commit
  6. 04 Dec, 2013 1 commit
  7. 03 Dec, 2013 1 commit
  8. 02 Dec, 2013 1 commit
  9. 22 Nov, 2013 6 commits
  10. 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.
  11. 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
    • 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)
  12. 01 Oct, 2013 1 commit
  13. 14 Sep, 2013 1 commit
  14. 13 Sep, 2013 1 commit
  15. 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.
  16. 29 Aug, 2013 1 commit
  17. 23 Apr, 2013 1 commit
  18. 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
         - 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
  19. 21 Apr, 2013 1 commit
  20. 14 Feb, 2013 1 commit
  21. 30 Jan, 2013 2 commits
  22. 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
         <type> `TcUnify.isSubType` <type>
      fails to hold, where "isSubType" means "is provably more polymorphic than".
            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.
  23. 31 Oct, 2012 2 commits
    • Simon Peyton Jones's avatar
      Wibble to recent changes to TcErrors · 2677e428
      Simon Peyton Jones authored
    • 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
       * 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
         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).
  24. 19 Oct, 2012 2 commits
  25. 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
  26. 15 Oct, 2012 1 commit
  27. 04 Oct, 2012 1 commit
  28. 03 Oct, 2012 1 commit
  29. 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
  30. 21 Sep, 2012 1 commit
  31. 17 Sep, 2012 1 commit