1. 22 Feb, 2012 1 commit
  2. 16 Feb, 2012 4 commits
  3. 16 Jan, 2012 1 commit
  4. 15 Jan, 2012 2 commits
  5. 14 Jan, 2012 1 commit
  6. 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
      5508ada4
  7. 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.
      
      Specifically:
      
       * 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.
      98a642cf
  8. 12 Dec, 2011 1 commit
  9. 23 Nov, 2011 1 commit
  10. 16 Nov, 2011 1 commit
  11. 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 http://haskell.org/haskellwiki/GHC/Kinds
      09015be8
  12. 10 Nov, 2011 7 commits
  13. 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
      b994313a
  14. 04 Nov, 2011 2 commits
  15. 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
      ====================
      
      Profilng
      --------
      
      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
      future.
      
      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
         tabs)
      
      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.
      
      Tickets
      =======
      
      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)
      7bb0447d
  16. 27 Sep, 2011 1 commit
  17. 21 Sep, 2011 1 commit
  18. 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
      de8c8d68
  19. 06 Sep, 2011 1 commit
    • batterseapower's avatar
      Implement -XConstraintKind · 9729fe7c
      batterseapower authored
      Basically as documented in http://hackage.haskell.org/trac/ghc/wiki/KindFact,
      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)
      9729fe7c
  20. 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.
      de9b85fa
  21. 24 Aug, 2011 1 commit
  22. 18 Aug, 2011 1 commit
  23. 05 Aug, 2011 1 commit
  24. 03 Aug, 2011 1 commit
  25. 02 Aug, 2011 4 commits
    • Simon Peyton Jones's avatar
      6ef8b031
    • Simon Peyton Jones's avatar
      Don't bleat about non-External names in mkUsageInfo · bdf364e8
      Simon Peyton Jones authored
      See Note [Internal used_names].  Fixes Trac #5362.
      bdf364e8
    • Simon Peyton Jones's avatar
      Change the representation of export lists in .hi files · fe44af73
      Simon Peyton Jones authored
      Currently export list in .hi files are partitioned by module
        export M T(C1,C2)
               N f,g
      In each list we only have OccNames, all assumed to come from
      the parent module M or N resp.
      
      This patch changes the representatation so that export lists
      have full Names:
        export M.T(M.C1,M.C2), N.f, N.g
      
      Numerous advatages
        * AvailInfo no longer needs to be parameterised; it always
          contains Names
      
        * Fixes Trac #5306.  This was the main provocation
      
        * Less to-and-fro conversion when reading interface files
      
      It's all generally simpler.  Interface files should not get bigger,
      becuase they have a nice compact representation for Names.
      fe44af73
    • Simon Peyton Jones's avatar
      Refactor the imports of InteractiveContext · 35d213ab
      Simon Peyton Jones authored
      Instead of two fields
         ic_toplev_scope :: [Module]
         ic_imports      :: [ImportDecl RdrName]
      
      we now just have one
         ic_imports :: [InteractiveImport]
      with the auxiliary data type
         data InteractiveImport
          = IIDecl (ImportDecl RdrName)  -- Bring the exports of a particular module
          	   	       		   -- (filtered by an import decl) into scope
      
          | IIModule Module	-- Bring into scope the entire top-level envt of
          	     		-- of this module, including the things imported
      			-- into it.
      
      This makes lots of code less confusing.  No change in behaviour.
      It's preparatory to fixing Trac #5147.
      
      While I was at I also
        * Cleaned up the handling of the "implicit" Prelude import
          by adding a ideclImplicit field to ImportDecl.  This
          significantly reduces plumbing in the handling of
          the implicit Prelude import
      
        * Used record notation consistently for ImportDecl
      35d213ab
  26. 21 Jul, 2011 1 commit
    • Simon Peyton Jones's avatar
      Change loop breaker terminology · e815d4b1
      Simon Peyton Jones authored
      We used to have "loop breaker" and "non-rule loop breaker", but
      the unqualified version in particualr was pretty confusing.  So
      now we have "strong loop breaker" and "weak loop breaker";
      comments in BasicTypes and OccurAnal.
      e815d4b1