1. 28 May, 2009 1 commit
  2. 12 May, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Improve error messages for type functions · da2e18b9
      simonpj@microsoft.com authored
      Following a suggestion of Claus Reinke, this patch improves the error
      messages involving type functions.  Here's the relevant note from TcTyFuns.
      Note [Non-injective type functions]
      It's very confusing to get a message like
           Couldn't match expected type `Depend s'
                  against inferred type `Depend s1'
      so pp_open_tc adds:
             NB: `Depend' is a (non-injective) type function
      Currently we add this independently for each argument, so we also get
           Couldn't match expected type `a'
                  against inferred type `Dual (Dual a)'
             NB: `Dual' is a (non-injective) type function
      which is arguably redundant.  But on the other hand, it's probably
      a good idea for the programmer to know the error involves type functions
      so I've left it in for now.  The obvious alternative is to only add
      this NB in the case of matching (T ...) ~ (T ...). 
  3. 27 Apr, 2009 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Equality constraint solver is now externally pure · 296058a1
      chak@cse.unsw.edu.au. authored
      - This patch changes the equality constraint solver such that it does not
        instantiate any type variables that occur in the constraints that are to be
        solved (or in the environment).  Instead, it returns a bag of type bindings.
      - If these type bindings (together with the other results of the solver) are
        discarded, solver invocation has no effect (outside the solver) and can be
        repeated (that's imported for TcSimplifyRestricted).
      - For the type bindings to take effect, the caller of the solver needs to 
        execute them. 
      - The solver will still instantiate type variables thet were created during 
        solving (e.g., skolem flexibles used during type flattening).
        See also http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsSolving
  4. 15 Mar, 2009 1 commit
  5. 04 Feb, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #2999: change an ASSERT to a WARN · 9524fc33
      simonpj@microsoft.com authored
      A bug in the constraint simplifier means that an equality can be solved
      twice.  It's harmless, and will go away with the new constraint simplifier.
      Hence warning, to avoid unnecessary outright failure on eg Trac #2999.
  6. 14 Jan, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Robustify lookupFamInstEnv · 27759873
      simonpj@microsoft.com authored
      Suppose we have
              type family T a :: * -> *
              type instance T Int = []
      and now we encounter the type (T Int Bool).  That is perfectly
      fine, even though T is over-saturated here.
      This patch makes lookupFamInstEnv robust to such over-saturation.
      Previously one caller (TcTyFuns.tcUnfoldSynFamInst) dealt with
      the over-saturation case, but the others did not. It's better
      to desl with the issue at the root, in lookupFamInstEnv itself.
  7. 02 Oct, 2008 1 commit
  8. 01 Oct, 2008 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      TcSimplify.reduceImplication: clean up · cfda0421
      chak@cse.unsw.edu.au. authored
      - This cleans up some of the mess in reduceImplication and documents the
        precondition on the form of wanted equalities properly.
      - I also made the back off test a bit smarter by allowing to back off in the
        presence of wanted equalities as long as none of them got solved in the
        attempt.  (That should save generating some superfluous bindings.)
        MERGE TO 6.10
  9. 30 Sep, 2008 1 commit
  10. 29 Sep, 2008 2 commits
  11. 25 Sep, 2008 2 commits
  12. 18 Sep, 2008 1 commit
  13. 17 Sep, 2008 1 commit
  14. 16 Sep, 2008 3 commits
  15. 15 Sep, 2008 1 commit
  16. 14 Sep, 2008 2 commits
  17. 13 Sep, 2008 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Type families: completed the new equality solver · e8917205
      chak@cse.unsw.edu.au. authored
      - Implements normalisation of class constraints containing synonym family
        applications or skolems refined by local equalities.
      - Clean up of TcSimplify.reduceContext by using the new equality solver.
      - Removed all the now unused code of the old algorithm.
      - This completes the implementation of the new algorithm, but it is largely
        untested => many regressions.
  18. 07 Sep, 2008 1 commit
  19. 12 Apr, 2008 1 commit
  20. 22 Apr, 2008 1 commit
  21. 29 Mar, 2008 1 commit
  22. 15 Mar, 2008 1 commit
  23. 13 Mar, 2008 2 commits
    • chak@cse.unsw.edu.au.'s avatar
      Some cleanup in TcSimplify.reduceContext · b5a8dd88
      chak@cse.unsw.edu.au. authored
      - Makes this horrid function a bit better - and shorter!
      - Also gets rid of another API function of TcTyFuns
    • chak@cse.unsw.edu.au.'s avatar
      Properly normalise reduced dicts · 3bbdfc75
      chak@cse.unsw.edu.au. authored
      - Another chapter in the never-ending TcSimplify.reduceContext saga: after
        context reduction of wanted dicts it is not sufficient to normalise them
        wrt to the wanted equalities.  We also need to take top-level equalities
        into account.  (In fact, we probably also have to normalise wrt to given
        equalities, but I have left that open for the moment - but added a TODO
      - This finally eliminates substEqInDictInsts from TcTyFuns interface and
        suggest some further possible clean up (which will be in a separate patch).
      Thanks to Roman for the intricate example that uncovered this bug.
  24. 26 Feb, 2008 1 commit
  25. 17 Jan, 2008 1 commit
  26. 07 Jan, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Make the treatment of equalities more uniform · 3787d987
      simonpj@microsoft.com authored
      This patch (which is part of the fix for Trac #2018) makes coercion variables
      be handled more uniformly.  Generally, they are treated like dictionaries
      in the type checker, not like type variables, but in a couple of places we
      were treating them like type variables.  Also when zonking we should use
      zonkDictBndr not zonkIdBndr.
  27. 07 Dec, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Properly keep track of whether normalising given or wanted dicts · b6d08641
      chak@cse.unsw.edu.au. authored
      - The information of whether given or wanted class dictionaries where
        normalised by rewriting wasn't always correctly propagated in TcTyFuns,
        which lead to malformed dictionary bindings.
      - Also fixes a bug in TcPat.tcConPat where GADT equalities where emitted in
        the wrong position in case bindings (which led to CoreLint failures).
  28. 01 Nov, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Rejig the error messages a bit; fixes a minor bug · 2e68d041
      simonpj@microsoft.com authored
      The type checker was only reporting the first message if an equality
      failed to match.  This patch does a bit of refactoring and fixes the
      bug, which was in the bogus use of eqInstMisMatch 
      in tcSimplify.report_no_instances.b
      This is really a bug in 6.8 too, so this would be good to merge across
      to the 6.8 branch.
  29. 19 Oct, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Zonk quantified tyvars with skolems · cad764aa
      chak@cse.unsw.edu.au. authored
      We used to zonk quantified type variables to regular TyVars.  However, this
      leads to problems.  Consider this program from the regression test suite:
        eval :: Int -> String -> String -> String
        eval 0 root actual = evalRHS 0 root actual
        evalRHS :: Int -> a
        evalRHS 0 root actual = eval 0 root actual
      It leads to the deferral of an equality
        (String -> String -> String) ~ a
      which is propagated up to the toplevel (see TcSimplify.tcSimplifyInferCheck).
      In the meantime `a' is zonked and quantified to form `evalRHS's signature.
      This has the *side effect* of also zonking the `a' in the deferred equality
      (which at this point is being handed around wrapped in an implication
      Finally, the equality (with the zonked `a') will be handed back to the
      simplifier by TcRnDriver.tcRnSrcDecls calling TcSimplify.tcSimplifyTop.
      If we zonk `a' with a regular type variable, we will have this regular type
      variable now floating around in the simplifier, which in many places assumes to
      only see proper TcTyVars.
      We can avoid this problem by zonking with a skolem.  The skolem is rigid
      (which we requirefor a quantified variable), but is still a TcTyVar that the
      simplifier knows how to deal with.
  30. 18 Oct, 2007 1 commit
  31. 15 Oct, 2007 1 commit
  32. 04 Oct, 2007 1 commit
  33. 03 Oct, 2007 1 commit
  34. 16 Sep, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      FIX: TypeFamilies: should_compile/Simple12 · 1b6b0ba3
      chak@cse.unsw.edu.au. authored
      - checkTauTvUpdate now distinguishes between whether
        (1) a type variables occurs only in type family parameters
            (in which case unification is to be deferred)
        (2) other variable occurences
            (which case we fail with a cannot create infinite type message, as before)