1. 27 Nov, 2006 1 commit
  2. 24 Nov, 2006 2 commits
  3. 20 Nov, 2006 1 commit
    • wolfgang.thaller@gmx.net's avatar
      i386-darwin: disable use of code stubs for dynamic linking · 5cfeedcc
      wolfgang.thaller@gmx.net authored
      We can't use lazy binding for tail-calls accross shared libraries, because dyld
      will crash due to incorrect stack layout. We can't get the stack alignment right for
      both cross-library tailcalls and foreign calls, so we have to bypass the stub code altogether
      and load the address to branch to from the non-lazy pointer table.
  4. 22 Oct, 2006 2 commits
  5. 25 Nov, 2006 2 commits
  6. 05 Nov, 2006 1 commit
  7. 24 Nov, 2006 11 commits
    • simonpj@microsoft.com's avatar
      Fix constraint handling for lazy patterns · 36d207aa
      simonpj@microsoft.com authored
      Lazy patterns are quite tricky!  Consider
      	f ~(C x) = 3
      Can the Num constraint from the 3 be discharged by a Num dictionary
      bound by the pattern?  Definitely not!  
      See Note [Hopping the LIE in lazy patterns] in TcPat
      The type checker wasn't ensuring this, and that was causing all
      manner of strange things to happen.  It actually manifested as a
      strictness bug reported by Sven Panne.
      I've added his test case as tcrun040.
    • sven.panne@aedion.de's avatar
    • Simon Marlow's avatar
      small stats fix · 63b6c933
      Simon Marlow authored
    • simonpj@microsoft.com's avatar
      Make SpecConstr more aggressive, by neglecting reboxing · d8a34b36
      simonpj@microsoft.com authored
      SpecConstr was conservative about avoiding reboxing (see Note [Reboxing])
      but that meant it lost useful opportunities.  This patch makes it much
      more aggressive, but at the risk of doing some reboxing.
      Actually, the strictness analyser has the same property (it's possible
      for it to generate reboxing code, and thus increase allocation), but we
      don't worry so much about that.  Maybe we should.
      Ideally, one would do some more sophisticated analysis that spotted
      the reboxing cases without excluding the useful ones.  
      But meanwhile, let's try this. 
    • simonpj@microsoft.com's avatar
    • simonpj@microsoft.com's avatar
      Improve handling of implicit parameters · 2e9952b7
      simonpj@microsoft.com authored
      A message to Haskell Cafe from Grzegorz Chrupala made me realise that
      GHC was not handling implicit parameters correctly, when it comes to
      choosing the variables to quantify, and ambiguity tests.  Here's the 
      note I added to TcSimplify:
      Note [Implicit parameters and ambiguity] 
      What type should we infer for this?
      	f x = (show ?y, x::Int)
      Since we must quantify over the ?y, the most plausible type is
      	f :: (Show a, ?y::a) => Int -> (String, Int)
      But notice that the type of the RHS is (String,Int), with no type 
      varibables mentioned at all!  The type of f looks ambiguous.  But
      it isn't, because at a call site we might have
      	let ?y = 5::Int in f 7
      and all is well.  In effect, implicit parameters are, well, parameters,
      so we can take their type variables into account as part of the
      "tau-tvs" stuff.  This is done in the function 'FunDeps.grow'.
      The actual changes are in FunDeps.grow, and the tests are
      	tc219, tc219
    • simonpj@microsoft.com's avatar
      Fix name-capture bug in rule matching · dfcbc18e
      simonpj@microsoft.com authored
      The matching algorithm for RULES should respect alpha-conversion, but it
      wasn't doing so.  In particular, if the names of the template variables
      clashed with a variable in scope at the call site, bad things could happen
      (it showed up as a CoreLint failure when compiling nofib/real/parser)
      This patch fixes the problem; see Note [Template binders]
      Test is in simplCore/should_compile/spec002, but nofib -O2 in
      	real/parser, real/fulsom
    • simonpj@microsoft.com's avatar
      Improve hashing of expressions · 9ba6b031
      simonpj@microsoft.com authored
      We were getting too many cases where different expressions map to the
      same hash code (which shows up in CSE). This patch tries to improve
      the hash algorithm a bit.
    • simonpj@microsoft.com's avatar
    • simonpj@microsoft.com's avatar
    • simonpj@microsoft.com's avatar
      Gather constraints in program order · ecd655aa
      simonpj@microsoft.com authored
      Provoked by a suggestion of Simon's, this patch makes a half-hearted attempt
      to gather constraints in program order, so that we tend to report an error
      at its first occurrence, rather than its last.  Examples:
      	mdofail001, tcfail015
      It's "half-hearted" because generally-speaking the typechecker does not
      guaranteed to keep constraints in order; it treats them as a set.  Nevertheless
      this very small change seems to improve matters, so it seems a good one.
  8. 23 Nov, 2006 2 commits
    • simonpj@microsoft.com's avatar
      Simplify TcSimplify, by removing Free · a3a15a64
      simonpj@microsoft.com authored
      For a long time TcSimplify used a three-way classification of constraints, 
      into 	Free
      (see the data type WhatToDo).  In the new world of implication constraints,
      the Free case does not make so much sense, and I managed to elminate it
      altogether, thus simplifying the story somewhat.  Now WhatToDo has constructors
      There should be no change in behaviour.
    • Simon Marlow's avatar
      fix failing assertion · 831f57c9
      Simon Marlow authored
  9. 22 Nov, 2006 7 commits
  10. 21 Nov, 2006 6 commits
  11. 20 Nov, 2006 4 commits
  12. 09 Nov, 2006 1 commit