1. 27 Oct, 2007 2 commits
  2. 07 Oct, 2007 1 commit
  3. 27 Oct, 2007 1 commit
  4. 26 Oct, 2007 3 commits
  5. 27 Oct, 2007 8 commits
    • simonpj@microsoft.com's avatar
      Make 'improvement' work properly in TcSimplify · 6ac37f3b
      simonpj@microsoft.com authored
      	(Please merge this, and the preceding 
      	handful from me to the 6.8 branch.)
      This patch fixes a serious problem in the type checker, whereby
      TcSimplify was going into a loop because it thought improvement
      had taken place, but actually the unificataion was actually deferred.
      We thereby fix Trac #1781, #1783, #1795, and #1797!
      In fixing this I found what a mess TcSimplify.reduceContext is! 
      We need to fix this.
      The main idea is to replace the "improvement flag" in Avails with
      a simpler and more direct test: have any of the mutable type variables
      in the (zonked) 'given' or 'irred' constraints been filled in?
      This test uses the new function TcMType.isFilledMetaTyVar; the test
      itself is towards the end of reduceContext.
      I fixed a variety of other infelicities too, and left some ToDos.
    • simonpj@microsoft.com's avatar
    • simonpj@microsoft.com's avatar
      In an AbsBinds, the 'dicts' can include EqInsts · 6bb65108
      simonpj@microsoft.com authored
      An AbsBinds abstrats over evidence, and the evidence can be both
      Dicts (class constraints, implicit parameters) and EqInsts (equality
      constraints).  So we need to
        - use varType rather than idType
        - use instToVar rather than instToId
        - use zonkDictBndr rather than zonkIdBndr in zonking
      It actually all worked before, but gave warnings.
    • simonpj@microsoft.com's avatar
      More notes · 0f8aee2a
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Comments only · 0a599d22
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Add anyM to IOEnv · 7018caf5
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Add a note to NOTES · 0119f79b
      simonpj@microsoft.com authored
    • chevalier@alum.wellesley.edu's avatar
      Make compileToCore return the module name and type environment along with bindings · 8102af4e
      chevalier@alum.wellesley.edu authored
        compileToCore returned just a list of CoreBind, which isn't enough,
      since to do anything with the resulting Core code, you probably also
      want the type declarations. I left compileToCore as it is, but added a
      function compileToCoreModule that returns a complete Core module (with
      module name, type environment, and bindings). I'm not sure that
      returning the type environment is the best way to represent the type
      declarations for the given module, but I don't want to reinvent the
      External Core wheel for this.
  6. 25 Oct, 2007 5 commits
  7. 24 Oct, 2007 5 commits
  8. 23 Oct, 2007 1 commit
  9. 24 Oct, 2007 2 commits
  10. 23 Oct, 2007 2 commits
  11. 22 Oct, 2007 1 commit
  12. 18 Oct, 2007 1 commit
    • Simon Marlow's avatar
      add PIC relocations for x86_64, and use a simpler hack in place of x86_64_high_symbol() · 2fc88e73
      Simon Marlow authored
      This is Wolfgang Thaller's patch sent to cvs-ghc recently, with extra
      commentary by me.  It turns out that this patch is not just a cleanup,
      it is also necessary for GHCi to work on x86_64 with shared libraries,
      because previously lookupSymbol() was creating jump-table entries for
      all symbols looked up that resolved outside 2Gb, whereas Wolfgang's
      version only generates jump-table entries for 32-bit symbol references
      in object code that we load.
  13. 17 Oct, 2007 1 commit
  14. 16 Oct, 2007 1 commit
  15. 19 Oct, 2007 2 commits
    • Simon Marlow's avatar
      second attempt to fix C compiler warnings with -fhpc · a0d2d5bb
      Simon Marlow authored
      The hs_hpc_module() prototype in RtsExternal.h didn't match its usage:
      we were passing StgWord-sized parameters but the prototype used C
      ints.  I think it accidentally worked because we only ever passed
      constants that got promoted.  The constants unfortunately were
      sometimes negative, which caused the C compiler to emit warnings.
      I suspect PprC.pprHexVal may be wrong to emit negative constants in
      the generated C, but I'm not completely sure.  Anyway, it's easy to
      fix this in CgHpc, which is what I've done.
    • chak@cse.unsw.edu.au.'s avatar
      Zonk quantified tyvars with skolems · cad764aa
      chak@cse.unsw.edu.au. authored
      We used to zonk quantified type variables to regular TyVars.  However, this
      leads to problems.  Consider this program from the regression test suite:
        eval :: Int -> String -> String -> String
        eval 0 root actual = evalRHS 0 root actual
        evalRHS :: Int -> a
        evalRHS 0 root actual = eval 0 root actual
      It leads to the deferral of an equality
        (String -> String -> String) ~ a
      which is propagated up to the toplevel (see TcSimplify.tcSimplifyInferCheck).
      In the meantime `a' is zonked and quantified to form `evalRHS's signature.
      This has the *side effect* of also zonking the `a' in the deferred equality
      (which at this point is being handed around wrapped in an implication
      Finally, the equality (with the zonked `a') will be handed back to the
      simplifier by TcRnDriver.tcRnSrcDecls calling TcSimplify.tcSimplifyTop.
      If we zonk `a' with a regular type variable, we will have this regular type
      variable now floating around in the simplifier, which in many places assumes to
      only see proper TcTyVars.
      We can avoid this problem by zonking with a skolem.  The skolem is rigid
      (which we requirefor a quantified variable), but is still a TcTyVar that the
      simplifier knows how to deal with.
  16. 18 Oct, 2007 1 commit
  17. 19 Oct, 2007 2 commits
  18. 18 Oct, 2007 1 commit