1. 06 Nov, 2012 4 commits
    • Simon Peyton Jones's avatar
      Refine the "kick-out" predicate for CTyVarEq · 545bb796
      Simon Peyton Jones authored
         Work item:   k ~ *
         Inert item:  (a::k) ~ Int
      Then we must kick out the inert item!  We weren't doing that,
      something I discovered when fixing Trac #7384.
      Discussed with Dimitrios, and we wrote a long comment
      Note [Delicate equality kick-out] to explain.
    • Simon Peyton Jones's avatar
      Make rewriteCtFlavor lazy in the coercion for Derived evidence · 4dade857
      Simon Peyton Jones authored
      I think I accidentally introduced this bug a month ago when
      refactoring. It's a bit non-obvious, but since Derived constraints
      have no evidence, we mustn't be strict in it.  Now there's a big
      comment to prevent this bug happening again.
      This fixes Trac #7384.
    • Simon Peyton Jones's avatar
      Fix the instantiation of data constructors in the GHCi debugger · acbe5265
      Simon Peyton Jones authored
      This bug caused Trac #7386, because in the (rather tricky) "type
      inference" (aka run time type reconstruction) done by the GHCi
      debugger, we were failing to instantiate a data type family
      correctly.  When that code was written we didn't *have* data
      I wrote Note [Constructor arg types] to explain the new scheme.
    • Simon Peyton Jones's avatar
      Comments only · 6ca46167
      Simon Peyton Jones authored
  2. 05 Nov, 2012 2 commits
  3. 02 Nov, 2012 11 commits
  4. 01 Nov, 2012 5 commits
  5. 31 Oct, 2012 3 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).
    • Simon Peyton Jones's avatar
      Comments only · 4baebfae
      Simon Peyton Jones authored
  6. 30 Oct, 2012 7 commits
  7. 29 Oct, 2012 2 commits
  8. 26 Oct, 2012 4 commits
  9. 25 Oct, 2012 2 commits