1. 06 Nov, 2014 13 commits
  2. 05 Nov, 2014 10 commits
  3. 04 Nov, 2014 17 commits
    • Simon Peyton Jones's avatar
      A little refactoring of HsSplice and friends · 6a1c05f0
      Simon Peyton Jones authored
      Plus adding comments.
      The most substantive change is that PendingTcSplice becomes a proper
      data type rather than a pair; and PendingRnSplice uses it
    • Herbert Valerio Riedel's avatar
      Re-center perf-numbers for T5631 · 64dc4d10
      Herbert Valerio Riedel authored
    • Herbert Valerio Riedel's avatar
      Remove redundant "Minimal complete definition"-comments · 1408c8dc
      Herbert Valerio Riedel authored
      Those manual descriptions in Haddock strings have become redundant since
      Haddock gained the ability to print the minimal complete definition as
      specified via `{-# MINIMAL #-}` annotation (or otherwise inferred by
      Moreover, this commit moves all `{-# MINIMAL #-}` annotations in `base`
      to the start of the respective `class` definitions, as this is more
      readable and matches more closely the way Haddock renders that
    • Simon Peyton Jones's avatar
      Test Trac #9750 · fe178b27
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Test Trac #9081 · 09aac7da
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
    • Simon Peyton Jones's avatar
      Simon's major commit to re-engineer the constraint solver · 5770029a
      Simon Peyton Jones authored
      The driving change is this:
      * The canonical CFunEqCan constraints now have the form
             [G] F xis ~ fsk
             [W] F xis ~ fmv
        where fsk is a flatten-skolem, and fmv is a flatten-meta-variable
        Think of them as the name of the type-function application
      See Note [The flattening story] in TcFlatten.  A flatten-meta-variable
      is distinguishable by its MetaInfo of FlatMetaTv
      This in turn led to an enormous cascade of other changes, which simplify
      and modularise the constraint solver.  In particular:
      * Basic data types
          * I got rid of inert_solved_funeqs altogether. It serves no useful
            role that inert_flat_cache does not solve.
          * I added wl_implics to the WorkList, as a convenient place to
            accumulate newly-emitted implications; see Note [Residual
            implications] in TcSMonad.
          * I eliminated tcs_ty_binds altogether. These were the bindings
            for unification variables that we have now solved by
            unification.  We kept them in a finite map and did the
            side-effecting unification later.  But in cannonicalisation we
            had to look up in the side-effected mutable tyvars anyway, so
            nothing was being gained.
            Our original idea was that the solver would be pure, and would
            be a no-op if you discarded its results, but this was already
            not-true for implications since we update their evidence
            bindings in an imperative way.  So rather than the uneasy
            compromise, it's now clearly imperative!
      * I split out the flatten/unflatten code into a new module, TcFlatten
      * I simplified and articulated explicitly the (rather hazy) invariants
        for the inert substitution inert_eqs.  See Note [eqCanRewrite] and
        See Note [Applying the inert substitution] in TcFlatten
      * Unflattening is now done (by TcFlatten.unflatten) after solveFlats,
        before solving nested implications.  This turned out to simplify a
        lot of code. Previously, unflattening was done as part of zonking, at
        the very very end.
          * Eager unflattening allowed me to remove the unpleasant ic_fsks
            field of an Implication (hurrah)
          * Eager unflattening made the TcSimplify.floatEqualities function
            much simpler (just float equalities looking like a ~ ty, where a
            is an untouchable meta-tyvar).
          * Likewise the idea of "pushing wanteds in as givens" could be
            completely eliminated.
      * I radically simplified the code that determines when there are
        'given' equalities, and hence whether we can float 'wanted' equalies
        out.  See TcSMonad.getNoGivenEqs, and Note [When does an implication
        have given equalities?].
        This allowed me to get rid of the unpleasant inert_no_eqs flag in InertCans.
      * As part of this given-equality stuff, I fixed Trac #9211. See Note
        [Let-bound skolems] in TcSMonad
      * Orientation of tyvar/tyvar equalities (a ~ b) was partly done during
        canonicalisation, but then repeated in the spontaneous-solve stage
        (trySpontaneousSolveTwoWay). Now it is done exclusively during
        canonicalisation, which keeps all the code in one place.  See
        Note [Canonical orientation for tyvar/tyvar equality constraints]
        in TcCanonical
    • Simon Peyton Jones's avatar
      Compiler performance is much worse in for loopy givens · ce9d6f25
      Simon Peyton Jones authored
      This is a deliberate choice, to simplify code, invariants, and I think
      performance in typical cases.  The "loopy givens" case is situations like
         [G]  a ~ TF (a, Int)
      where TF is a type function with TF (a,b) = (TF a, TF b).
      See Note [An alternative story for the inert substitution] in TcFlatten.
    • Simon Peyton Jones's avatar
      Make this test a bit simpler · f02c915c
      Simon Peyton Jones authored
      There were two unrelated functions, and the `-ddump-rule-firings` output
      was coming in a non-deterministic order as a result. So now there is just
      one function.
    • Simon Peyton Jones's avatar
      Add flattening-notes · 652a5efe
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Testsuite error message changes · 5479ae0a
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Comments only · 66658eed
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Fix the superclass-cycle detection code (Trac #9739) · 7c796336
      Simon Peyton Jones authored
      We were falling into an infinite loop when doing the ambiguity
      check on a class method, even though we had previously detected
      a superclass cycle.  There was code to deal with this, but it
      wasn't right.
    • Simon Peyton Jones's avatar
      Test Trac #9739 · c639560d
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Add comments explaining ProbOneShot · abfbdd1c
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Test Trac #9747 · dbbffb7b
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar