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. 12 Oct, 2012 2 commits
  2. 09 Oct, 2012 1 commit
    • ian@well-typed.com's avatar
      Make the opt_UF_* static flags dynamic · 0a768bcb
      ian@well-typed.com authored
      I also removed the default values from the "Discounts and thresholds"
      note: most of them were no longer up-to-date.
      
      Along the way I added FloatSuffix to the argument parser, analogous to
      IntSuffix.
      0a768bcb
  3. 18 Sep, 2012 1 commit
    • Simon Peyton Jones's avatar
      Make a start towards eta-rules and injective families · 58470fb7
      Simon Peyton Jones authored
      * Make Any into a type family (which it should always have been)
        This is to support the future introduction of eta rules for
        product types (see email on ghc-users title "PolyKind issue"
        early Sept 2012)
      
      * Add the *internal* data type support for
          (a) closed type families [so that you can't give
              type instance for 'Any']
          (b) injective type families [because Any is really
              injective]
        This amounts to two boolean flags on the SynFamilyTyCon
        constructor of TyCon.SynTyConRhs.
      
      There is some knock-on effect, but all of a routine nature.
      
      It remains to offer source syntax for either closed or
      injective families.
      58470fb7
  4. 17 Sep, 2012 1 commit
    • Simon Peyton Jones's avatar
      Implement 'left' and 'right' coercions · af7cc995
      Simon Peyton Jones authored
      This patch finally adds 'left' and 'right' coercions back into
      GHC.  Trac #7205 gives the details.
      
      The main change is to add a new constructor to Coercion:
      
        data Coercion
          = ...
          | NthCo  Int         Coercion     -- OLD, still there
          | LRCo   LeftOrRight Coercion     -- NEW
      
        data LeftOrRight = CLeft | CRight
      
      Plus:
        * Similar change to TcCoercion
        * Use LRCo when decomposing AppTys
        * Coercion optimisation needs to handle left/right
      
      The rest is just knock-on effects.
      af7cc995
  5. 16 Sep, 2012 1 commit
  6. 05 Sep, 2012 1 commit
  7. 23 Aug, 2012 1 commit
  8. 07 Aug, 2012 1 commit
  9. 02 Aug, 2012 1 commit
  10. 24 Jul, 2012 1 commit
  11. 16 Jul, 2012 3 commits
  12. 15 Jul, 2012 1 commit
  13. 10 Jul, 2012 1 commit
    • Simon Peyton Jones's avatar
      More changes to kind inference for type and class declarations · 3fe3ef50
      Simon Peyton Jones authored
      These should fix #7024 and #7022, among others.
      
      The main difficulty was that we were getting occ-name clashes
      between kind and type variables in TyCons, when spat into an
      interface file. The new scheme is to tidy TyCons during the
      conversoin into IfaceSyn, rather than trying to generate them
      pre-tidied, which was the already-unsatisfactory previous plan.
      
      There is the usual wave of refactorig as well.
      3fe3ef50
  14. 27 Jun, 2012 1 commit
    • Simon Peyton Jones's avatar
      Add silent superclass parameters (again) · aa1e0976
      Simon Peyton Jones authored
      Silent superclass parameters solve the problem that
      the superclasses of a dicionary construction can easily
      turn out to be (wrongly) bottom.  The problem and solution
      are described in
         Note [Silent superclass arguments] in TcInstDcls
      
      I first implemented this fix (with Dimitrios) in Dec 2010, but removed
      it again in Jun 2011 becuase we thought it wasn't necessary any
      more. (The reason we thought it wasn't necessary is that we'd stopped
      generating derived superclass constraints for *wanteds*.  But we were
      wrong; that didn't solve the superclass-loop problem.)
      
      So we have to re-implement it.  It's not hard.  Main features:
      
        * The IdDetails for a DFunId says how many silent arguments it has
      
        * A DFunUnfolding describes which dictionary args are
          just parameters (DFunLamArg) and which are a function to apply
          to the parameters (DFunPolyArg).  This adds the DFunArg type
          to CoreSyn
      
        * Consequential changes to IfaceSyn.  (Binary hi file format changes
          slightly.)
      
        * TcInstDcls changes to generate the right dfuns
      
        * CoreSubst.exprIsConApp_maybe handles the new DFunUnfolding
      
      The thing taht is *not* done yet is to alter the vectoriser to
      pass the relevant extra argument when building a PA dictionary.
      aa1e0976
  15. 22 Jun, 2012 2 commits
  16. 18 Jun, 2012 2 commits
  17. 15 Jun, 2012 1 commit
  18. 13 Jun, 2012 1 commit
    • Simon Peyton Jones's avatar
      Simplify the implementation of Implicit Parameters · 5a8ac0f8
      Simon Peyton Jones authored
      This patch re-implements implicit parameters via a class
      with a functional dependency:
      
          class IP (n::Symbol) a | n -> a where
            ip :: a
      
      This definition is in the library module GHC.IP. Notice
      how it use a type-literal, so we can have constraints like
         IP "x" Int
      Now all the functional dependency machinery works right to make
      implicit parameters behave as they should.
      
      Much special-case processing for implicit parameters can be removed
      entirely. One particularly nice thing is not having a dedicated
      "original-name cache" for implicit parameters (the nsNames field of
      NameCache).  But many other cases disappear:
      
        * BasicTypes.IPName
        * IPTyCon constructor in Tycon.TyCon
        * CIPCan constructor  in TcRnTypes.Ct
        * IPPred constructor  in Types.PredTree
      
      Implicit parameters remain special in a few ways:
      
       * Special syntax.  Eg the constraint (IP "x" Int) is parsed
         and printed as (?x::Int).  And we still have local bindings
         for implicit parameters, and occurrences thereof.
      
       * A implicit-parameter binding  (let ?x = True in e) amounts
         to a local instance declaration, which we have not had before.
         It just generates an implication contraint (easy), but when
         going under it we must purge any existing bindings for
         ?x in the inert set.  See Note [Shadowing of Implicit Parameters]
         in TcSimplify
      
       * TcMType.sizePred classifies implicit parameter constraints as size-0,
         as before the change
      
      There are accompanying patches to libraries 'base' and 'haddock'
      
      All the work was done by Iavor Diatchki
      5a8ac0f8
  19. 12 Jun, 2012 3 commits
  20. 11 Jun, 2012 1 commit
    • Ian Lynagh's avatar
      Pass DynFlags to the LogAction · 5716a2f8
      Ian Lynagh authored
      A side-effect is that we can no longer use the LogAction in
      defaultErrorHandler, as we don't have DynFlags at that point.
      But all that defaultErrorHandler did is to print Strings as
      SevFatal, so now it takes a 'FatalMessager' instead.
      5716a2f8
  21. 06 Jun, 2012 1 commit
  22. 05 Jun, 2012 1 commit
  23. 29 May, 2012 1 commit
    • Ian Lynagh's avatar
      Replace printDump with a new Severity · 78252479
      Ian Lynagh authored
      We now use log_action with severity SevDump, rather than calling
      printDump. This means that what happens to dumped info is now under
      the control of the GHC API user, rather than always going to stdout.
      78252479
  24. 28 May, 2012 1 commit
  25. 02 May, 2012 1 commit
    • Simon Peyton Jones's avatar
      Allow cases with empty alterantives · ac230c5e
      Simon Peyton Jones authored
      This patch allows, for the first time, case expressions with an empty
      list of alternatives. Max suggested the idea, and Trac #6067 showed
      that it is really quite important.
      
      So I've implemented the idea, fixing #6067. Main changes
      
       * See Note [Empty case alternatives] in CoreSyn
      
       * Various foldr1's become foldrs
      
       * IfaceCase does not record the type of the alternatives.
         I added IfaceECase for empty-alternative cases.
      
       * Core Lint does not complain about empty cases
      
       * MkCore.castBottomExpr constructs an empty-alternative case
         expression   (case e of ty {})
      
       * CoreToStg converts '(case e of {})' to just 'e'
      ac230c5e
  26. 30 Apr, 2012 1 commit
    • Simon Peyton Jones's avatar
      Make the interface-file deserialisation work right for promoted types (Trac #6054) · e57c8667
      Simon Peyton Jones authored
      GHC currently uses the slightly-dodgy plan that when we proote
      a TyCon to be a Kind constructor we leave it with the same Name.
      
      That means that to make sense of a IfaceType we need to know wheter
      it is really an IfaceType or an IfaceKind, because in the latter an
      occurrence of (say) Maybe will be the *promoted* Maybe.
      
      See Note [Checking IfaceTypes vs IfaceKinds] in TcIface
      e57c8667
  27. 27 Apr, 2012 1 commit
  28. 25 Apr, 2012 1 commit
  29. 04 Apr, 2012 1 commit
  30. 28 Mar, 2012 1 commit
  31. 18 Mar, 2012 1 commit
    • Iavor S. Diatchki's avatar
      Fix the printing of * (the kind). · 452e15a9
      Iavor S. Diatchki authored
      Type and kinds use the same printing code, but the kind * is not
      an infix operator and so it should not be wrapped in parens.
      
      As is, 'parenSymOcc', can't get this right because it does not know
      if it is looking at *, the type, or *, the kind.   This is why I
      added a special case in 'ppr_tc'.
      452e15a9
  32. 05 Mar, 2012 1 commit
  33. 01 Mar, 2012 1 commit
    • Simon Marlow's avatar
      In --make, give an indication of why a module is being recompiled · 27d7d930
      Simon Marlow authored
      e.g.
      
      [3 of 5] Compiling C                (C.hs, C.o)
      [4 of 5] Compiling D                (D.hs, D.o) [C changed]
      [5 of 5] Compiling E                (E.hs, E.o) [D changed]
      
      The main motivation for this is so that we can give the user a clue
      when something is being recompiled because the flags changed:
      
      [1 of 1] Compiling Test2            ( Test2.hs, Test2.o ) [flags changed]
      27d7d930