1. 18 Jun, 2011 2 commits
    • dterei's avatar
      SafeHaskell: Transitively check safety when compiling a module. · 77d85a4a
      dterei authored
      While we previously checked the safety of safe imported modules we
      didn't do this check transitively. This can be a problem when we depend
      on a trustworthy module in a package that is no longer trusted, so we
      should fail compilation. We already stored in an interface file the
      transitive list of packages a module depends on. Now we extend that list
      to include a flag saying if we depend on that package being trusted as
      well.
      77d85a4a
    • dterei's avatar
      6de1b0f2
  2. 17 May, 2011 1 commit
    • dimitris's avatar
      Introducing: · 9591547f
      dimitris authored
         1) Postponing the application of instances when there
            is a possibility of a given matching. With the addition
            of prioritizing equalities this fixes #5002 and #4981.
      
         2) Implemented caching of flattening in constraint
            simplification. This improves efficiency (fixes #5030)
      
         3) Simplified pushing of unsolved wanteds
            (now pushing only equalities) inside implications.
      9591547f
  3. 28 Apr, 2011 1 commit
  4. 26 Apr, 2011 1 commit
  5. 20 Apr, 2011 1 commit
  6. 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
  7. 20 Feb, 2011 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Added a VECTORISE pragma · f2aaae97
      chak@cse.unsw.edu.au. authored
      - Added a pragma {-# VECTORISE var = exp #-} that prevents
        the vectoriser from vectorising the definition of 'var'.
        Instead it uses the binding '$v_var = exp' to vectorise
        'var'.  The vectoriser checks that the Core type of 'exp'
        matches the vectorised Core type of 'var'.  (It would be
        quite complicated to perform that check in the type checker
        as the vectorisation of a type needs the state of the VM
        monad.)
      - Added parts of a related VECTORISE SCALAR pragma
      - Documented -ddump-vect
      - Added -ddump-vt-trace
      - Some clean up
      f2aaae97
  8. 17 Feb, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Use "on the spot" solving for fundeps · 50d02935
      simonpj@microsoft.com authored
      When we spot an equality arising from a functional dependency,
      we now use that equality (a "wanted") to rewrite the work-item
      constraint right away.  This avoids two dangers
      
       Danger 1: If we send the original constraint on down the pipeline
                 it may react with an instance declaration, and in delicate
      	   situations (when a Given overlaps with an instance) that
      	   may produce new insoluble goals: see Trac #4952
      
       Danger 2: If we don't rewrite the constraint, it may re-react
                 with the same thing later, and produce the same equality
                 again --> termination worries.
      
      To achieve this required some refactoring of FunDeps.lhs (nicer
      now!).  
      
      This patch also contains a couple of unrelated improvements
      
      * A bad bug in TcSMonad.nestImplicTcS whereby the Tcs tyvars
        of an outer implication were not untouchable inside
      
      * Improved logging machinery for the type constraint solver;
        use -ddump-cs-trace (probably with a wider default line width
        -dppr-cols=200 or something)
      50d02935
  9. 09 Feb, 2011 1 commit
  10. 13 Jan, 2011 1 commit
  11. 12 Jan, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Major refactoring of the type inference engine · 27310213
      simonpj@microsoft.com authored
      This patch embodies many, many changes to the contraint solver, which
      make it simpler, more robust, and more beautiful.  But it has taken
      me ages to get right. The forcing issue was some obscure programs
      involving recursive dictionaries, but these eventually led to a
      massive refactoring sweep.
      
      Main changes are:
       * No more "frozen errors" in the monad.  Instead "insoluble
         constraints" are now part of the WantedConstraints type.
      
       * The WantedConstraint type is a product of bags, instead of (as
         before) a bag of sums.  This eliminates a good deal of tagging and
         untagging.
      
       * This same WantedConstraints data type is used
           - As the way that constraints are gathered
           - As a field of an implication constraint
           - As both argument and result of solveWanted
           - As the argument to reportUnsolved
      
       * We do not generate any evidence for Derived constraints. They are
         purely there to allow "impovement" by unifying unification
         variables.
      
       * In consequence, nothing is ever *rewritten* by a Derived
         constraint.  This removes, by construction, all the horrible
         potential recursive-dictionary loops that were making us tear our
         hair out.  No more isGoodRecEv search either. Hurrah!
      
       * We add the superclass Derived constraints during canonicalisation,
         after checking for duplicates.  So fewer superclass constraints
         are generated than before.
      
       * Skolem tc-tyvars no longer carry SkolemInfo.  Instead, the
         SkolemInfo lives in the GivenLoc of the Implication, where it
         can be tidied, zonked, and substituted nicely.  This alone is
         a major improvement.
      
       * Tidying is improved, so that we tend to get t1, t2, t3, rather
         than t1, t11, t111, etc
      
         Moreover, unification variables are always printed with a digit
         (thus a0, a1, etc), so that plain 'a' is available for a skolem
         arising from a type signature etc. In this way,
           (a) We quietly say which variables are unification variables,
               for those who know and care
           (b) Types tend to get printed as the user expects.  If he writes
                   f :: a -> a
                   f = ...blah...
               then types involving 'a' get printed with 'a', rather than
               some tidied variant.
      
       * There are significant improvements in error messages, notably
         in the "Cannot deduce X from Y" messages.
      27310213
  12. 02 Dec, 2010 1 commit
  13. 12 Nov, 2010 1 commit
    • simonpj@microsoft.com's avatar
      A (final) re-engineering of the new typechecker · c80364f8
      simonpj@microsoft.com authored
      Regression testing and user feedback for GHC 7.0 taught
      us a lot.  This patch fixes numerous small bugs, and some
      major ones (eg Trac #4484, #4492), and improves type
      error messages.
      
      The main changes are:
      
      * Entirely remove the "skolem equivalance class" stuff;
        a very useful simplification
      
      * Instead, when flattening "wanted" constraints we generate
        unification variables (not flatten-skolems) for the
        flattened type function application
      
      * We then need a fixup pass at the end, TcSimplify.solveCTyFunEqs,
        which resolves any residual equalities of form
            F xi ~ alpha
      
      * When we come across a definite failure (e.g. Int ~ [a]),
        we now defer reporting the error until the end, in case we
        learn more about 'a'.  That is particularly important for
        occurs-check errors.  These are called "frozen" type errors.
      
      * Other improvements in error message generation.
      
      * Better tracing messages
      c80364f8
  14. 22 Oct, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Add rebindable syntax for if-then-else · 4e0c994e
      simonpj@microsoft.com authored
      There are two main changes
      
       * New LANGUAGE option RebindableSyntax, which implies NoImplicitPrelude
      
       * if-the-else becomes rebindable, with function name "ifThenElse"
         (but case expressions are unaffected)
      
      Thanks to Sam Anklesaria for doing most of the work here
      4e0c994e
  15. 21 Oct, 2010 1 commit
  16. 08 Oct, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Beautiful new approach to the skolem-escape check and untouchable · debb7b80
      simonpj@microsoft.com authored
      Instead of keeping a *set* of untouchable variables in each
      implication contraints, we keep a *range* of uniques for the
      *touchable* variables of an implication.  This are precisely
      the ones we would call the "existentials" if we were French.
      
      It turns out that the code is more efficient, and vastly easier
      to get right, than the set-based approach.
      
      Fixes Trac #4355 among others
      debb7b80
  17. 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
  18. 06 Oct, 2010 1 commit
  19. 19 Sep, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Add a flag -fwarn-missing-local-sigs, and improve -fwarn-mising-signatures · e8fa04cf
      simonpj@microsoft.com authored
      The new flag prints out a warning if you have a local,
      polymorphic binding that lacks a type signature. It's meant
      to help with the transition to the new typechecker, which
      discourages local let-generalisation.
      
      At the same time I moved the missing-signature code to TcHsSyn,
      where it takes place as part of zonking.  That way the 
      types are reported after all typechecking is complete,
      thereby fixing Trac #3696.  (It's even more important for
      local bindings, which is why I made the change.)
      e8fa04cf
  20. 17 Sep, 2010 1 commit
  21. 13 Sep, 2010 1 commit
  22. 20 Mar, 2010 1 commit
  23. 10 Feb, 2010 1 commit
  24. 30 Nov, 2009 1 commit
  25. 10 Sep, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Three improvements to Template Haskell (fixes #3467) · 1e436f2b
      simonpj@microsoft.com authored
      This patch implements three significant improvements to Template Haskell.
        
      Declaration-level splices with no "$" 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      This change simply allows you to omit the "$(...)" wrapper for 
      declaration-level TH splices.  An expression all by itself is
      not legal, so we now treat it as a TH splice.  Thus you can now
      say
      	data T = T1 | T2
       	deriveMyStuff ''T
      
      where deriveMyStuff :: Name -> Q [Dec]
      This makes a much nicer interface for clients of libraries that use
      TH: no scary $(deriveMyStuff ''T).
      
      Nested top-level splices
      ~~~~~~~~~~~~~~~~~~~~~~~~
      Previously TH would reject this, saying that splices cannot be nested:
      	f x = $(g $(h 'x))
      But there is no reason for this not to work.  First $(h 'x) is run,
      yielding code <blah> that is spliced instead of the $(h 'x). Then (g
      <blah>) is typechecked and run, yielding code that replaces the
      $(g ...) splice.  
      
      So this simply lifts the restriction.
      
      Fix Trac #3467: non-top-level type splices
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      It appears that when I added the ability to splice types in TH
      programs, I failed to pay attention to non-top-level splices -- that
      is, splices inside quotatation brackets.  
      
      This patch fixes the problem.  I had to modify HsType, so there's a
      knock-on change to Haddock.
      
      Its seems that a lot of lines of code has changed, but almost all the
      new lines are comments!
      
      General tidying up
      ~~~~~~~~~~~~~~~~~~
      As a result of thinking all this out I re-jigged the data type ThStage,
      which had far too many values before.  And I wrote a nice state transition
      diagram to make it all precise; 
         see Note [Template Haskell state diagram] in TcSplice
      
      Lots more refactoring in TcSplice, resulting in significantly less code.
      (A few more lines, but actually less code -- the rest is comments.)
      
      I think the result is significantly cleaner.
      1e436f2b
  26. 26 Aug, 2009 1 commit
  27. 23 Jul, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3012: allow more free-wheeling in standalone deriving · aa0c0de9
      simonpj@microsoft.com authored
      In standalone deriving, we now do *not* check side conditions.
      We simply generate the code and typecheck it.  If there's a type
      error, it's the programmer's problem. 
      
      This means that you can do 'deriving instance Show (T a)', where
      T is a GADT, for example, provided of course that the boilerplate
      code does in fact typecheck.
      
      I put some work into getting a decent error message.  In particular
      if there's a type error in a method, GHC will show the entire code
      for that method (since, after all, the user did not write it).
      Most of the changes are to achieve that goal.
      
      Still to come: changes in the documentation.
      aa0c0de9
  28. 16 Jul, 2009 1 commit
    • Simon Marlow's avatar
      Use names like '$fOrdInt' for dfuns (and TF instances), rather than '$f21' · a6f29db0
      Simon Marlow authored
      2 reasons for this:
        - compilation is more predictable.  Adding or removing an instance
          is less likely to force unnecessary recompilation due to
          renumbering other dfun names.
        - it makes it easier to read Core / C-- / asm
      
      The names aren't completely deterministic.  To do that, we'd have to
      include package and module names, which would make the symbol names
      long and reduce readability.  So the compromise is that if there's a
      clash, we disambiguate by adding an integer suffix.  This is fairly
      unlikely in practice unless you're using overlapping instances.
      
      Type family instances are handled in the same way, with the same
      disambiguation strategy.
      a6f29db0
  29. 07 Jul, 2009 1 commit
  30. 06 Jul, 2009 1 commit
  31. 27 Apr, 2009 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Equality constraint solver is now externally pure · 296058a1
      chak@cse.unsw.edu.au. authored
      - This patch changes the equality constraint solver such that it does not
        instantiate any type variables that occur in the constraints that are to be
        solved (or in the environment).  Instead, it returns a bag of type bindings.
      - If these type bindings (together with the other results of the solver) are
        discarded, solver invocation has no effect (outside the solver) and can be
        repeated (that's imported for TcSimplifyRestricted).
      - For the type bindings to take effect, the caller of the solver needs to 
        execute them. 
      - The solver will still instantiate type variables thet were created during 
        solving (e.g., skolem flexibles used during type flattening).
      
        See also http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsSolving
      296058a1
  32. 30 Jan, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #2985: generating superclasses and recursive dictionaries · c04a5fe3
      simonpj@microsoft.com authored
      The Note [Recursive instances and superclases] explains the subtle
      issues to do with generating the bindings for superclasses when
      we compile an instance declaration, at least if we want to do the
      clever "recursive superclass" idea from the SYB3 paper.
      
      The old implementation of tcSimplifySuperClasses stumbled when
      type equalities entered the picture (details in the Note); this
      patch fixes the problem using a slightly hacky trick.  When we
      re-engineer the constraint solver we'll want to keep an eye on 
      this.
      
      Probably worth merging to the 6.10 branch.
      
      c04a5fe3
  33. 11 Dec, 2008 1 commit
  34. 30 Oct, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Add (a) CoreM monad, (b) new Annotations feature · 9bcd95ba
      simonpj@microsoft.com authored
      This patch, written by Max Bolingbroke,  does two things
      
      1.  It adds a new CoreM monad (defined in simplCore/CoreMonad),
          which is used as the top-level monad for all the Core-to-Core
          transformations (starting at SimplCore).  It supports
             * I/O (for debug printing)
             * Unique supply
             * Statistics gathering
             * Access to the HscEnv, RuleBase, Annotations, Module
          The patch therefore refactors the top "skin" of every Core-to-Core
          pass, but does not change their functionality.
      
      2.  It adds a completely new facility to GHC: Core "annotations".
          The idea is that you can say
             {#- ANN foo (Just "Hello") #-}
          which adds the annotation (Just "Hello") to the top level function
          foo.  These annotations can be looked up in any Core-to-Core pass,
          and are persisted into interface files.  (Hence a Core-to-Core pass
          can also query the annotations of imported things.)  Furthermore,
          a Core-to-Core pass can add new annotations (eg strictness info)
          of its own, which can be queried by importing modules.
      
      The design of the annotation system is somewhat in flux.  It's
      designed to work with the (upcoming) dynamic plug-ins mechanism,
      but is meanwhile independently useful.
      
      Do not merge to 6.10!  
      9bcd95ba
  35. 28 Oct, 2008 1 commit
  36. 15 Oct, 2008 1 commit
  37. 02 Oct, 2008 1 commit
  38. 07 Sep, 2008 1 commit
  39. 11 Aug, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Make comparison on equalities work right (ie look at the types) · 7539ed8c
      simonpj@microsoft.com authored
      This patch makes
      	(s1~t1) == (s2~t2) iff s1==s2, t1==t2
      
      The comparison and equality instances for Insts are really only
      used in making the AvailEnv in TcSimplify, which equalities are
      never put into, which is why we've gotten away with this for so long.
      
      But I'm now using 'nub' in the error messages for equalities,
      and in any case it makes sense to have the right equality!
      7539ed8c