This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 13 Dec, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix recursive superclasses (again). Fixes Trac #4809. · a3bab050
      simonpj@microsoft.com authored
      This patch finally deals with the super-delicate question of
      superclases in possibly-recursive dictionaries.  The key idea
      is the DFun Superclass Invariant (see TcInstDcls):
      
           In the body of a DFun, every superclass argument to the
           returned dictionary is
             either   * one of the arguments of the DFun,
             or       * constant, bound at top level
      
      To establish the invariant, we add new "silent" superclass
      argument(s) to each dfun, so that the dfun does not do superclass
      selection internally.  There's a bit of hoo-ha to make sure that
      we don't print those silent arguments in error messages; a knock
      on effect was a change in interface-file format.
      
      A second change is that instead of the complex and fragile
      "self dictionary binding" in TcInstDcls and TcClassDcl,
      using the same mechanism for existential pattern bindings.
      See Note [Subtle interaction of recursion and overlap] in TcInstDcls
      and Note [Binding when looking up instances] in InstEnv.
      
      Main notes are here:
      
        * Note [Silent Superclass Arguments] in TcInstDcls,
          including the DFun Superclass Invariant
      
      Main code changes are:
      
        * The code for MkId.mkDictFunId and mkDictFunTy
      
        * DFunUnfoldings get a little more complicated;
          their arguments are a new type DFunArg (in CoreSyn)
      
        * No "self" argument in tcInstanceMethod
        * No special tcSimplifySuperClasss
        * No "dependents" argument to EvDFunApp
      
      IMPORTANT
         It turns out that it's quite tricky to generate the right
         DFunUnfolding for a specialised dfun, when you use SPECIALISE
         INSTANCE.  For now I've just commented it out (in DsBinds) but
         that'll lose some optimisation, and I need to get back to
         this.
      a3bab050
  2. 10 Dec, 2010 1 commit
  3. 09 Dec, 2010 1 commit
    • dimitris@microsoft.com's avatar
      Moved canonicalisation inside solveInteract · ef6d82a4
      dimitris@microsoft.com authored
      Moreover canonicalisation now is "clever", i.e. it never canonicalizes a class 
      constraint if it can already discharge it from some other inert or previously
      encountered constraints. See Note [Avoiding the superclass explosion]
      ef6d82a4
  4. 13 Dec, 2010 1 commit
  5. 12 Dec, 2010 1 commit
  6. 10 Dec, 2010 6 commits
  7. 08 Dec, 2010 1 commit
  8. 10 Dec, 2010 7 commits
  9. 08 Dec, 2010 6 commits
  10. 09 Dec, 2010 3 commits
  11. 08 Dec, 2010 2 commits
  12. 23 Nov, 2010 1 commit
    • boris's avatar
      :unset settings support · e639fb47
      boris authored
      Added support for settings [args, prog, prompt, editor and stop].
      Now :unset supports the same set of options as :set.
      e639fb47
  13. 08 Dec, 2010 1 commit
  14. 03 Dec, 2010 1 commit
  15. 07 Dec, 2010 1 commit
    • Ian Lynagh's avatar
      Make CPPFLAGS variables, as well as CFLAGS and LDFLAGS · 75cd9c50
      Ian Lynagh authored
      This fixes the "does unsetenv return void" test in the unix package on
      OS X, if I tell it to make 10.4-compatible binaries. The test uses
      CPPFLAGS but not CFLAGS, so it thought it returned int (as it was
      in 10.5-mode), but the C compiler (using CFLAGS, so in 10.4 mode)
      thought it returned void.
      
      I also added CONF_LD_OPTS_STAGE$3 to the list of things in LDFLAGS,
      which looks like an accidental ommission.
      75cd9c50
  16. 06 Dec, 2010 3 commits
  17. 05 Dec, 2010 2 commits
  18. 03 Dec, 2010 1 commit