1. 09 Mar, 2013 7 commits
  2. 08 Mar, 2013 5 commits
  3. 07 Mar, 2013 4 commits
  4. 06 Mar, 2013 1 commit
  5. 05 Mar, 2013 3 commits
  6. 04 Mar, 2013 15 commits
  7. 03 Mar, 2013 5 commits
    • Simon Peyton Jones's avatar
      Comments and type signatures only · 2bd278d3
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Treat equalities with incompatible kinds as "irreducible" constraints · c969cc3d
      Simon Peyton Jones authored
      Originally we had the invariant that CTyEqCan and CFunEqCan have LHS
      and RHS with compatible kinds.  This is important because if they have
      different kinds, then a substitution using the CTyEqCan can give rise
      to an ill-kinded type, which in turn makes typeKind crash, and this
      led to Trac #7696.  (The possibility of this happening really only
      occurred when we introduced kind polymorphism.)
      I thought at first this was going to be really awkward to solve, but
      happily it turned out to be easy.  We already have CIrredEvCan
      constraints, which are "stuck"; we can't use them and we can't solve
      them.  Yet. After some substitution from solving other constraints we
      may be able to make progress.
      So for equality constraints where the LHS and RHS don't have compatible kinds
      (although perhaps not YET compatible, eg k and *, just needing to
      unify k := *), we now generate a CIrredEvCan, plus the necessary kind
      equality constraint.
      This entailed some refactoring of course, but only in TcCanonical.  In
      particular, the emitKindConstraint code has gone, in favour of a kind
      check in canEqLeaf.  See Note [Equalities with incompatible kinds] in
      TcCanonical, and Note [CIrredEvCan constraints] in TcRnTypes
    • Simon Peyton Jones's avatar
      Make sure that Constraint is unrelated to other kinds in tcIsSubKind · 24a0e442
      Simon Peyton Jones authored
      This was causing the bug reported in Trac #7697
    • ian@well-typed.com's avatar
      Automatically add the $(exeext) to program names · 2b85372c
      ian@well-typed.com authored
      We now define _PROGNAME, and _PROG is automatically defined with
      $(exeext). This will shortly automatically use the right exeext
      depending on what stage it is being compiled with (exeext may be
      different for different stages when cross-compiling).
    • ian@well-typed.com's avatar