1. 19 Jan, 2012 1 commit
    • Ian Lynagh's avatar
      Fix validate · 8bdcc5cf
      Ian Lynagh authored
      This patch defines a flag -fno-warn-pointless-pragmas, and uses it to
      disable some warnings in the containers package.
      
      Along the way, also made a ContainsDynFlags class, and added a
      HasDynFlags instance for IOEnv (and thus TcRnIf and DsM).
      8bdcc5cf
  2. 17 Jan, 2012 1 commit
  3. 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
  4. 22 Dec, 2011 1 commit
  5. 05 Dec, 2011 1 commit
    • Simon Peyton Jones's avatar
      Allow full constraint solving under a for-all (Trac #5595) · 2e6dcdf7
      Simon Peyton Jones authored
      The main idea is that when we unify
          forall a. t1  ~  forall a. t2
      we get constraints from unifying t1~t2 that mention a.
      We are producing a coercion witnessing the equivalence of
      the for-alls, and inside *that* coercion we need bindings
      for the solved constraints arising from t1~t2.
      
      We didn't have way to do this before.  The big change is
      that here's a new type TcEvidence.TcCoercion, which is
      much like Coercion.Coercion except that there's a slot
      for TcEvBinds in it.
      
      This has a wave of follow-on changes. Not deep but broad.
      
      * New module TcEvidence, which now contains the HsWrapper
        TcEvBinds, EvTerm etc types that used to be in HsBinds
      
      * The typechecker works exclusively in terms of TcCoercion.
      
      * The desugarer converts TcCoercion to Coercion
      
      * The main payload is in TcUnify.unifySigmaTy. This is the
        function that had a gross hack before, but is now beautiful.
      
      * LCoercion is gone!  Hooray.
      
      Many many fiddly changes in conssequence.  But it's nice.
      2e6dcdf7
  6. 24 Nov, 2011 1 commit
    • Simon Peyton Jones's avatar
      Support "phase control" for SPECIALISE pragmas · 814d8641
      Simon Peyton Jones authored
      This featurelet allows Trac #5237 to be fixed.
      The idea is to allow SPECIALISE pragmas to specify
      the phases in which the RULE is active, just as you can
      do with RULES themselves.
        {-# SPECIALISE [1] foo :: Int -> Int #-}
      
      This feature is so obvious that not having it is really a bug.
      There are, needless to say, a few wrinkles.  See
         Note [Activation pragmas for SPECIALISE]
      in DsBinds
      814d8641
  7. 16 Nov, 2011 1 commit
  8. 04 Nov, 2011 1 commit
  9. 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
  10. 09 Sep, 2011 1 commit
  11. 07 Sep, 2011 1 commit
  12. 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
  13. 16 Aug, 2011 1 commit
    • Simon Peyton Jones's avatar
      Major improvement to pattern bindings · 49dbe605
      Simon Peyton Jones authored
      This patch makes a number of related improvements
      
      a) Implements the Haskell Prime semantics for pattern bindings
         (Trac #2357).  That is, a pattern binding p = e is typed
         just as if it had been written
              t = e
              f = case t of p -> f
              g = case t of p -> g
              ... etc ...
         where f,g are the variables bound by p. In paricular it's
         ok to say
            (f,g) = (\x -> x, \y -> True)
         and f and g will get propertly inferred types
            f :: a -> a
            g :: a -> Int
      
      b) Eliminates the MonoPatBinds flag altogether.  (For the moment
         it is deprecated and has no effect.)  Pattern bindings are now
         generalised as per (a).  Fixes Trac #2187 and #4940, in the
         way the users wanted!
      
      c) Improves the OutsideIn algorithm generalisation decision.
         Given a definition without a type signature (implying "infer
         the type"), the published algorithm rule is this:
            - generalise *top-level* functions, and
            - do not generalise *nested* functions
         The new rule is
            - generalise a binding whose free variables have
              Guaranteed Closed Types
            - do not generalise other bindings
      
         Generally, a top-level let-bound function has a Guaranteed
         Closed Type, and so does a nested function whose free vaiables
         are top-level functions, and so on. (However a top-level
         function that is bitten by the Monomorphism Restriction does
         not have a GCT.)
      
         Example:
           f x = let { foo y = y } in ...
         Here 'foo' has no free variables, so it is generalised despite
         being nested.
      
      d) When inferring a type f :: ty for a definition f = e, check that
         the compiler would accept f :: ty as a type signature for that
         same definition.  The type is rejected precisely when the type
         is ambiguous.
      
         Example:
            class Wob a b where
              to :: a -> b
              from :: b -> a
      
            foo x = [x, to (from x)]
         GHC 7.0 would infer the ambiguous type
            foo :: forall a b. Wob a b => b -> [b]
         but that type would give an error whenever it is called; and
         GHC 7.0 would reject that signature if given by the
         programmer.  The new type checker rejects it up front.
      
         Similarly, with the advent of type families, ambiguous types are
         easy to write by mistake.  See Trac #1897 and linked tickets for
         many examples.  Eg
            type family F a :: *
            f ::: F a -> Int
            f x = 3
         This is rejected because (F a ~ F b) does not imply a~b.  Previously
         GHC would *infer* the above type for f, but was unable to check it.
         Now even the inferred type is rejected -- correctly.
      
      The main implemenation mechanism is to generalise the abe_wrap
      field of ABExport (in HsBinds), from [TyVar] to HsWrapper. This
      beautiful generalisation turned out to make everything work nicely
      with minimal programming effort.  All the work was fiddling around
      the edges; the core change was easy!
      49dbe605
  14. 03 Aug, 2011 1 commit
  15. 21 Jul, 2011 1 commit
  16. 13 Jun, 2011 1 commit
  17. 02 May, 2011 1 commit
  18. 19 Apr, 2011 1 commit
    • Simon Peyton Jones's avatar
      This BIG PATCH contains most of the work for the New Coercion Representation · fdf86568
      Simon Peyton Jones authored
      See the paper "Practical aspects of evidence based compilation in System FC"
      
      * Coercion becomes a data type, distinct from Type
      
      * Coercions become value-level things, rather than type-level things,
        (although the value is zero bits wide, like the State token)
        A consequence is that a coerion abstraction increases the arity by 1
        (just like a dictionary abstraction)
      
      * There is a new constructor in CoreExpr, namely Coercion, to inject
        coercions into terms
      fdf86568
  19. 05 Jan, 2011 1 commit
  20. 01 Nov, 2010 1 commit
  21. 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
  22. 02 Dec, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Re-jig simplifySuperClass (again) · 5723262f
      simonpj@microsoft.com authored
      This fixes the current loop in T3731, and will fix other
      reported loops.  The loops show up when we are generating
      evidence for superclasses in an instance declaration.
      
      The trick is to make the "self" dictionary simplifySuperClass
      depend *explicitly* on the superclass we are currently trying
      to build.  See Note [Dependencies in self dictionaries] in TcSimplify.
      
      That in turn means that EvDFunApp needs a dependency-list, used
      when chasing dependencies in isGoodRecEv.
      5723262f
  23. 21 Oct, 2010 1 commit
  24. 18 Oct, 2010 1 commit
  25. 07 Oct, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Implement auto-specialisation of imported Ids · 92267aa2
      simonpj@microsoft.com authored
      This big-ish patch arranges that if an Id 'f' is 
        * Type-class overloaded 
             f :: Ord a => [a] -> [a]
        * Defined with an INLINABLE pragma
             {-# INLINABLE f #-}
        * Exported from its defining module 'D'
      
      then in any module 'U' that imports D
      
      1. Any call of 'f' at a fixed type will generate 
         (a) a specialised version of f in U
         (b) a RULE that rewrites unspecialised calls to the
             specialised on
      
        e.g. if the call is (f Int dOrdInt xs) then the 
        specialiser will generate
           $sfInt :: [Int] -> [Int]
           $sfInt = <code for f, imported from D, specialised>
           {-# RULE forall d.  f Int d = $sfInt #-}
      
      2. In addition, you can give an explicit {-# SPECIALISE -#}
         pragma for the imported Id
           {-# SPECIALISE f :: [Bool] -> [Bool] #-}
         This too generates a local specialised definition, 
         and the corresponding RULE 
      
      The new RULES are exported from module 'U', so that any module
      importing U will see the specialised versions of 'f', and will
      not re-specialise them.
      
      There's a flag -fwarn-auto-orphan that warns you if the auto-generated
      RULES are orphan rules. It's not in -Wall, mainly to avoid lots of
      error messages with existing packages.
      
      Main implementation changes
      
       - A new flag on a CoreRule to say if it was auto-generated.
         This is persisted across interface files, so there's a small
         change in interface file format.
      
       - Quite a bit of fiddling with plumbing, to get the 
         {-# SPECIALISE #-} pragmas for imported Ids.  In particular, a
         new field tgc_imp_specs in TcGblEnv, to keep the specialise
         pragmas for imported Ids between the typechecker and the desugarer.
      
       - Some new code (although surprisingly little) in Specialise,
         to deal with calls of imported Ids
      92267aa2
  26. 24 Sep, 2010 1 commit
  27. 15 Sep, 2010 1 commit
  28. 13 Sep, 2010 1 commit
  29. 31 May, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Robustify the treatement of DFunUnfolding · a90dc390
      simonpj@microsoft.com authored
      See Note [DFun unfoldings] in CoreSyn.  The issue here is that 
      you can't tell how many dictionary arguments a DFun needs just
      from looking at the Arity of the DFun Id: if the dictionary is
      represented by a newtype the arity might include the dictionary
      and value arguments of the (single) method.
      
      So we need to record the number of arguments need by the DFun
      in the DFunUnfolding itself.  Details in 
         Note [DFun unfoldings] in CoreSyn
      a90dc390
  30. 10 May, 2010 1 commit
  31. 31 Mar, 2010 1 commit
  32. 09 Mar, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Rule binders shouldn't have DFun pragmas · 81e41fe3
      simonpj@microsoft.com authored
      When DsBinds deals with a SPECIALISE pragma, it makes up the binders
      for a RULE. These binders should be very vanilla: no IdInfo of any sort.
      But the way it was before they could have DFun pragmas, which led to
      Bad Joss downstream.  (Actually to cause a downstream *error* was itself
      a bug, which I've fixed, but it's clearly wrong for them to be DFuns!)
      81e41fe3
  33. 08 Jan, 2010 1 commit
  34. 06 Jan, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Improve the handling of default methods · 77166b17
      simonpj@microsoft.com authored
      See the long Note [INLINE and default methods].  
      
      This patch changes a couple of data types, with a knock-on effect on
      the format of interface files.  A lot of files get touched, but is a
      relatively minor change.  The main tiresome bit is the extra plumbing
      to communicate default methods between the type checker and the
      desugarer.
      77166b17
  35. 21 Dec, 2009 1 commit
  36. 02 Dec, 2009 1 commit
    • simonpj@microsoft.com's avatar
      More work on the simplifier's inlining strategies · c86161c5
      simonpj@microsoft.com authored
      This patch collects a small raft of related changes
      
      * Arrange that during 
           (a) rule matching and 
           (b) uses of exprIsConApp_maybe
        we "look through" unfoldings only if they are active
        in the phase. Doing this for (a) required a bit of 
        extra plumbing in the rule matching code, but I think
        it's worth it.
      
        One wrinkle is that even if inlining is off (in the 'gentle'
        phase of simplification) during rule matching we want to
        "look through" things with inlinings.  
         See SimplUtils.activeUnfInRule.
      
        This fixes a long-standing bug, where things that were
        supposed to be (say) NOINLINE, could still be poked into
        via exprIsConApp_maybe. 
      
      * In the above cases, also check for (non-rule) loop breakers; 
        we never look through these.  This fixes a bug that could make
        the simplifier diverge (and did for Roman).  
        Test = simplCore/should_compile/dfun-loop
      
      * Try harder not to choose a DFun as a loop breaker. This is 
        just a small adjustment in the OccurAnal scoring function
      
      * In the scoring function in OccurAnal, look at the InlineRule
        unfolding (if there is one) not the actual RHS, beause the
        former is what'll be inlined.  
      
      * Make the application of any function to dictionary arguments
        CONLIKE.  Thus (f d1 d2) is CONLIKE.  
        Encapsulated in CoreUtils.isExpandableApp
        Reason: see Note [Expandable overloadings] in CoreUtils
      
      * Make case expressions seem slightly smaller in CoreUnfold.
        This reverses an unexpected consequences of charging for
        alternatives.
      
      Refactorings
      ~~~~~~~~~~~~
      * Signficantly refactor the data type for Unfolding (again). 
        The result is much nicer.  
      
      * Add type synonym BasicTypes.CompilerPhase = Int
        and use it
      
      Many of the files touched by this patch are simply knock-on
      consequences of these two refactorings.
      c86161c5
  37. 19 Nov, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Implement -fexpose-all-unfoldings, and fix a non-termination bug · 6a944ae7
      simonpj@microsoft.com authored
      The -fexpose-all-unfoldings flag arranges to put unfoldings for *everything*
      in the interface file.  Of course,  this makes the file a lot bigger, but
      it also makes it complete, and that's great for supercompilation; or indeed
      any whole-program work.
      
      Consequences:
        * Interface files need to record loop-breaker-hood.  (Previously,
          loop breakers were never exposed, so that info wasn't necessary.)
          Hence a small interface file format change. 
      
        * When inlining, must check loop-breaker-hood. (Previously, loop
          breakers didn't have an unfolding at all, so no need to check.)
      
        * Ditto in exprIsConApp_maybe.  Roman actually tripped this bug, 
          because a DFun, which had an unfolding, was also a loop breaker
      
        * TidyPgm.tidyIdInfo must be careful to preserve loop-breaker-hood
      
      So Id.idUnfolding checks for loop-breaker-hood and returns NoUnfolding
      if so. When you want the unfolding regardless of loop-breaker-hood, 
      use Id.realIdUnfolding.
      
      I have not documented the flag yet, because it's experimental.  Nor
      have I tested it thoroughly.  But with the flag off (the normal case)
      everything should work.
      6a944ae7
  38. 13 Nov, 2009 2 commits
  39. 30 Oct, 2009 1 commit