1. 10 Aug, 2006 9 commits
    • simonpj@microsoft.com's avatar
      Do not repeatedly simplify an argument more than once · c43e5edf
      simonpj@microsoft.com authored
      A very important invariant of the simplifier is that we do not simplify
      an arbitrarily large expression more than once in a single pass. If this
      can happen, then we can get exponential behaviour, when the large expression
      itself has a large sub-expression which is simplified twice, and so on.
      GHC has a long-standing bug which allows this repeated simplification to 
      happen.  It shows up when we have a function like this
      	f d BIG
      where f's unfolding looks like
      	\x -> case x of (a,b) -> a
      Of course this is v common for overloaded functions.
      Before this patch we simplified all the args (d and BIG) before
      deciding to unfold f.  Then we push back the simplified BIG onto the
      continuation stack, inline f, so now we have
      	(case d of (a,b) -> a) BIG
      After we reduce the case a bit, we'll simplify BIG a second time.  And
      that's the problem.
      The quick-and-dirty solution is to keep a flag in the ApplyTo continuation
      to say whather the arg has already been simplified.  An alternative would
      be to simplify it when first encountered, but that's a bigger change.
    • simonpj@microsoft.com's avatar
      Do not call preInlineUnconditionally in simplNonRecX · 3df4d7ee
      simonpj@microsoft.com authored
      This looks to me like a long-standing bug. simplNonRecX was calling
      preInlineUnconditionally, even though it was given an already-simplified
      expression.  Exponential behaviour beckons.
    • simonpj@microsoft.com's avatar
      Make postInlineUnconditaionally more conservative · 80965661
      simonpj@microsoft.com authored
      I'm being more paranoid about repeatedly simplifying things (to avoid
      exponential behaviour.)  postInlineUnconditionally looks as if it
      could repeated simplify the same expression; this patch stops it doing
      The extra lines are all comments!
    • Simon Marlow's avatar
    • Simon Marlow's avatar
      remove out of date comment · 69d5d326
      Simon Marlow authored
    • Simon Marlow's avatar
      move html before network, for now · 443f2650
      Simon Marlow authored
    • Simon Marlow's avatar
      add html package · 1a1102fd
      Simon Marlow authored
    • simonpj@microsoft.com's avatar
      Egregious bug in tcLHsConResTy · e656c6e3
      simonpj@microsoft.com authored
      This terrible bug in tcLHsConTy is pretty much guaranteed to show up
      on an program involving a GADT with more than one type parameter.
      This bug isn't present in the STABLE branch.
      Manuel: it is *not* necesary to merge this patch into the FC branch; 
      just ignore it.
    • simonpj@microsoft.com's avatar
  2. 09 Aug, 2006 14 commits
  3. 08 Aug, 2006 5 commits
  4. 06 Jul, 2006 3 commits
  5. 03 Jul, 2006 1 commit
  6. 08 Aug, 2006 3 commits
    • Simon Marlow's avatar
      Remember to free() memory on exit · 9f2ceb4d
      Simon Marlow authored
      Patch mostly from Lennart Augustsson in #803, with additions to
      Task.c by me.
    • simonpj@microsoft.com's avatar
      Fix pre-subsumption and pre-matching · 3098d214
      simonpj@microsoft.com authored
      The pre-subsuption and pre-matching functions should NEVER make bogus
      bindings of type variables, although they are free to bale out and make
      too few bindings.
      I hadn't been thiking carefully enough about this, and there were two
      separate bugs.  
      - Firstly, in pre-subsumption we must ignore the 'theta'
        part of any overloaded type.  
      - Second, in pre-matching, we must return the empty subustition 
        on a mis-match, rather than returning the substitution so far.
      This bug showed up when compiling Data.Generics.Schemes.hs, and is
      imortalised in test tc206
    • simonpj@microsoft.com's avatar
      Improve error message · d2b27dcd
      simonpj@microsoft.com authored
      Improve a little-used error message.  Given
      	f :: a -> a
      	f x y = e
      the error says 
      	The equations for f have two arguments
      	but its type `a -> a' has only one
      (Before, it said "its type `a' has only one" which is bogus.
  7. 10 Jul, 2006 2 commits
  8. 09 Jul, 2006 2 commits
  9. 08 Jul, 2006 1 commit