#2722: <<loop> when compiling with -O option with ghc-6.10.0.20081019
-----------------------------------------+----------------------------------
  Reporter:  uwe                         |          Owner:  simonpj       
      Type:  bug                         |         Status:  infoneeded    
  Priority:  normal                      |      Milestone:  7.0.3         
 Component:  libraries (other)           |        Version:  7.0.1         
Resolution:                              |       Keywords:  arrows        
  Testcase:  tyepcheck/should_run/T2722  |      Blockedby:                
Difficulty:  Unknown                     |             Os:  Linux         
  Blocking:                              |   Architecture:  x86_64 (amd64)
   Failure:  Runtime crash               |  
-----------------------------------------+----------------------------------
Changes (by simonpj):

  * status:  new => infoneeded
  * testcase:  => tyepcheck/should_run/T2722


Comment:

 OK I think this one is properly fixed now
 {{{
 Wed Jan 12 06:56:04 PST 2011  [email protected]
   * Major refactoring of the type inference engine

   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.

     M ./compiler/basicTypes/Name.lhs -1 +1
     M ./compiler/basicTypes/OccName.lhs -2 +4
     M ./compiler/basicTypes/Var.lhs -1 +4
     M ./compiler/ghci/RtClosureInspect.hs -5 +2
     M ./compiler/main/HscTypes.lhs -5 +9
     M ./compiler/main/InteractiveEval.hs -18 +32
     M ./compiler/typecheck/FamInst.lhs -2 +1
     M ./compiler/typecheck/Inst.lhs -42 +113
     M ./compiler/typecheck/TcArrows.lhs -1 +1
     M ./compiler/typecheck/TcBinds.lhs -16 +9
     M ./compiler/typecheck/TcCanonical.lhs -110 +162
     M ./compiler/typecheck/TcClassDcl.lhs -3 +2
     M ./compiler/typecheck/TcEnv.lhs +1
     M ./compiler/typecheck/TcErrors.lhs -298 +248
     M ./compiler/typecheck/TcExpr.lhs -3 +8
     M ./compiler/typecheck/TcHsSyn.lhs -1 +1
     M ./compiler/typecheck/TcHsType.lhs -2 +2
     M ./compiler/typecheck/TcInstDcls.lhs -23 +14
     M ./compiler/typecheck/TcInteract.lhs -336 +304
     M ./compiler/typecheck/TcMType.lhs -79 +119
     M ./compiler/typecheck/TcMatches.lhs -1 +1
     M ./compiler/typecheck/TcPat.lhs -6 +6
     M ./compiler/typecheck/TcRnDriver.lhs -4 +16
     M ./compiler/typecheck/TcRnMonad.lhs -7 +22
     M ./compiler/typecheck/TcRnTypes.lhs -103 +305
     M ./compiler/typecheck/TcRules.lhs -2 +3
     M ./compiler/typecheck/TcSMonad.lhs -270 +82
     M ./compiler/typecheck/TcSimplify.lhs -378 +427
     M ./compiler/typecheck/TcSplice.lhs -9 +10
     M ./compiler/typecheck/TcType.lhs -155 +87
     M ./compiler/typecheck/TcUnify.lhs -38 +39
     M ./compiler/types/FamInstEnv.lhs +3
     M ./compiler/types/Unify.lhs -31 +41
     M ./compiler/utils/Bag.lhs -1 +14
 }}}
 I've added a test taken from an earlier comment.  Could you try the HEAD
 (which will turn into GHC 7.0.2 soon) on your FRP example, please?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2722#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to