This project is mirrored from 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. 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'
  2. 04 Apr, 2012 1 commit
  3. 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
      [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]
  4. 27 Feb, 2012 1 commit
  5. 22 Feb, 2012 1 commit
  6. 16 Feb, 2012 4 commits
  7. 16 Jan, 2012 1 commit
  8. 15 Jan, 2012 2 commits
  9. 14 Jan, 2012 1 commit
  10. 12 Jan, 2012 1 commit
    • Simon Peyton Jones's avatar
      Implememt -fdefer-type-errors (Trac #5624) · 5508ada4
      Simon Peyton Jones authored
      This patch implements the idea of deferring (most) type errors to
      runtime, instead emitting only a warning at compile time.  The
      basic idea is very simple:
       * The on-the-fly unifier in TcUnify never fails; instead if it
         gets stuck it emits a constraint.
       * The constraint solver tries to solve the constraints (and is
         entirely unchanged, hooray).
       * The remaining, unsolved constraints (if any) are passed to
         TcErrors.reportUnsolved.  With -fdefer-type-errors, instead of
         emitting an error message, TcErrors emits a warning, AND emits
         a binding for the constraint witness, binding it
         to (error "the error message"), via the new form of evidence
         TcEvidence.EvDelayedError.  So, when the program is run,
         when (and only when) that witness is needed, the program will
         crash with the exact same error message that would have been
         given at compile time.
      Simple really.  But, needless to say, the exercise forced me
      into some major refactoring.
       * TcErrors is almost entirely rewritten
       * EvVarX and WantedEvVar have gone away entirely
       * ErrUtils is changed a bit:
           * New Severity field in ErrMsg
           * Renamed the type Message to MsgDoc (this change
             touches a lot of files trivially)
       * One minor change is that in the constraint solver we try
         NOT to combine insoluble constraints, like Int~Bool, else
         all such type errors get combined together and result in
         only one error message!
       * I moved some definitions from TcSMonad to TcRnTypes,
         where they seem to belong more
  11. 03 Jan, 2012 1 commit
    • Simon Peyton Jones's avatar
      Major refactoring of CoAxioms · 98a642cf
      Simon Peyton Jones authored
      This patch should have no user-visible effect.  It implements a
      significant internal refactoring of the way that FC axioms are
      handled.  The ultimate goal is to put us in a position to implement
      "pattern-matching axioms".  But the changes here are only does
      refactoring; there is no change in functionality.
       * We now treat data/type family instance declarations very,
         very similarly to types class instance declarations:
         - Renamed InstEnv.Instance as InstEnv.ClsInst, for symmetry with
           FamInstEnv.FamInst.  This change does affect the GHC API, but
           for the better I think.
         - Previously, each family type/data instance declaration gave rise
           to a *TyCon*; typechecking a type/data instance decl produced
           that TyCon.  Now, each type/data instance gives rise to
           a *FamInst*, by direct analogy with each class instance
           declaration giving rise to a ClsInst.
         - Just as each ClsInst contains its evidence, a DFunId, so each FamInst
           contains its evidence, a CoAxiom.  See Note [FamInsts and CoAxioms]
           in FamInstEnv.  The CoAxiom is a System-FC thing, and can relate any
           two types, whereas the FamInst relates directly to the Haskell source
           language construct, and always has a function (F tys) on the LHS.
         - Just as a DFunId has its own declaration in an interface file, so now
           do CoAxioms (see IfaceSyn.IfaceAxiom).
         These changes give rise to almost all the refactoring.
       * We used to have a hack whereby a type family instance produced a dummy
         type synonym, thus
            type instance F Int = Bool -> Bool
         translated to
            axiom FInt :: F Int ~ R:FInt
            type R:FInt = Bool -> Bool
         This was always a hack, and now it's gone.  Instead the type instance
         declaration produces a FamInst, whose axiom has kind
            axiom FInt :: F Int ~ Bool -> Bool
         just as you'd expect.
       * Newtypes are done just as before; they generate a CoAxiom. These
         CoAxioms are "implicit" (do not generate an IfaceAxiom declaration),
         unlike the ones coming from family instance declarations.  See
         Note [Implicit axioms] in TyCon
      On the whole the code gets significantly nicer.  There were consequential
      tidy-ups in the vectoriser, but I think I got them right.
  12. 12 Dec, 2011 1 commit
  13. 23 Nov, 2011 1 commit
  14. 16 Nov, 2011 1 commit
  15. 11 Nov, 2011 1 commit
    • dreixel's avatar
      New kind-polymorphic core · 09015be8
      dreixel authored
      This big patch implements a kind-polymorphic core for GHC. The current
      implementation focuses on making sure that all kind-monomorphic programs still
      work in the new core; it is not yet guaranteed that kind-polymorphic programs
      (using the new -XPolyKinds flag) will work.
      For more information, see
  16. 10 Nov, 2011 7 commits
  17. 05 Nov, 2011 1 commit
    • GregWeber's avatar
      addDependentFile #4900 · b994313a
      GregWeber authored
      Let GHC know about an external dependency that Template Haskell uses
      so that GHC can recompile when the dependency changes.
      No support for ghc -M
      There is a corresponding addition to the template-haskell library
  18. 04 Nov, 2011 2 commits
  19. 02 Nov, 2011 1 commit
    • Simon Marlow's avatar
      Overhaul of infrastructure for profiling, coverage (HPC) and breakpoints · 7bb0447d
      Simon Marlow authored
      User visible changes
      Flags renamed (the old ones are still accepted for now):
        OLD            NEW
        ---------      ------------
        -auto-all      -fprof-auto
        -auto          -fprof-exported
        -caf-all       -fprof-cafs
      New flags:
        -fprof-auto              Annotates all bindings (not just top-level
                                 ones) with SCCs
        -fprof-top               Annotates just top-level bindings with SCCs
        -fprof-exported          Annotates just exported bindings with SCCs
        -fprof-no-count-entries  Do not maintain entry counts when profiling
                                 (can make profiled code go faster; useful with
                                 heap profiling where entry counts are not used)
      Cost-centre stacks have a new semantics, which should in most cases
      result in more useful and intuitive profiles.  If you find this not to
      be the case, please let me know.  This is the area where I have been
      experimenting most, and the current solution is probably not the
      final version, however it does address all the outstanding bugs and
      seems to be better than GHC 7.2.
      Stack traces
      +RTS -xc now gives more information.  If the exception originates from
      a CAF (as is common, because GHC tends to lift exceptions out to the
      top-level), then the RTS walks up the stack and reports the stack in
      the enclosing update frame(s).
      Result: +RTS -xc is much more useful now - but you still have to
      compile for profiling to get it.  I've played around a little with
      adding 'head []' to GHC itself, and +RTS -xc does pinpoint the problem
      quite accurately.
      I plan to add more facilities for stack tracing (e.g. in GHCi) in the
      Coverage (HPC)
       * derived instances are now coloured yellow if they weren't used
       * likewise record field names
       * entry counts are more accurate (hpc --fun-entry-count)
       * tab width is now correct (markup was previously off in source with
      Internal changes
      In Core, the Note constructor has been replaced by
              Tick (Tickish b) (Expr b)
      which is used to represent all the kinds of source annotation we
      support: profiling SCCs, HPC ticks, and GHCi breakpoints.
      Depending on the properties of the Tickish, different transformations
      apply to Tick.  See CoreUtils.mkTick for details.
      This commit closes the following tickets, test cases to follow:
        - Close #2552: not a bug, but the behaviour is now more intuitive
          (test is T2552)
        - Close #680 (test is T680)
        - Close #1531 (test is result001)
        - Close #949 (test is T949)
        - Close #2466: test case has bitrotted (doesn't compile against current
          version of vector-space package)
  20. 27 Sep, 2011 1 commit
  21. 21 Sep, 2011 1 commit
  22. 09 Sep, 2011 1 commit
    • batterseapower's avatar
      Implement associated type defaults · de8c8d68
      batterseapower authored
      Basically, now you can write:
        class Cls a where
          type Typ a
          type Typ a = Just a
      And now if an instance does not specify an explicit associated type
      instance, one will be generated afresh based on that default. So for
      example this instance:
        instance Cls Int where
      Will be equivalent to this one:
        instance Cls Int where
          type Typ Int = Just Int
  23. 06 Sep, 2011 1 commit
    • batterseapower's avatar
      Implement -XConstraintKind · 9729fe7c
      batterseapower authored
      Basically as documented in,
      this patch adds a new kind Constraint such that:
        Show :: * -> Constraint
        (?x::Int) :: Constraint
        (Int ~ a) :: Constraint
      And you can write *any* type with kind Constraint to the left of (=>):
      even if that type is a type synonym, type variable, indexed type or so on.
      The following (somewhat related) changes are also made:
       1. We now box equality evidence. This is required because we want
          to give (Int ~ a) the *lifted* kind Constraint
       2. For similar reasons, implicit parameters can now only be of
          a lifted kind. (?x::Int#) => ty is now ruled out
       3. Implicit parameter constraints are now allowed in superclasses
          and instance contexts (this just falls out as OK with the new
          constraint solver)
      Internally the following major changes were made:
       1. There is now no PredTy in the Type data type. Instead
          GHC checks the kind of a type to figure out if it is a predicate
       2. There is now no AClass TyThing: we represent classes as TyThings
          just as a ATyCon (classes had TyCons anyway)
       3. What used to be (~) is now pretty-printed as (~#). The box
          constructor EqBox :: (a ~# b) -> (a ~ b)
       4. The type LCoercion is used internally in the constraint solver
          and type checker to represent coercions with free variables
          of type (a ~ b) rather than (a ~# b)
  24. 02 Sep, 2011 1 commit
    • Simon Peyton Jones's avatar
      Export a tiny bit more info with AbstractTyCon (fixes #5424) · de9b85fa
      Simon Peyton Jones authored
      When we compile -O0 we put type constructors in the interface file
      without their data constructors -- an AbstractTyCon.  But in a
      client module, to give good pattern-match exhaustiveness warnings,
      we need to know the difference between a data type and a newtype.
      (The latter can be coerced to another type, but a data type can't.)
      See Note [Pruning dead case alternatives] in Unify.
      Because we weren't conveying this info, we were getting bogus
      warnings about inexhaustive patterm matches with GADTs, and
      (confusingly) these warnings woudl come and go depending on
      whether you were compiling with -O.
      This patch makes AbstractTyCon carry a flag indicating whether
      the type constructor is "distinct"; two distinct TyCons cannot
      be coerced into eachother (except by unsafeCoerce, in which case
      all bets are off).
      HEADS UP: interface file format changes slightly, so you need
      to make clean.
  25. 24 Aug, 2011 1 commit
  26. 18 Aug, 2011 1 commit
  27. 05 Aug, 2011 1 commit
  28. 03 Aug, 2011 1 commit
  29. 02 Aug, 2011 1 commit