Changes between Version 158 and Version 159 of TypeFunctionsStatus


Ignore:
Timestamp:
Aug 27, 2007 5:52:36 AM (7 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TypeFunctionsStatus

    v158 v159  
    9191   tcfail102(normal) 
    9292   tcfail103(normal) 
     93   tcfail153(normal) 
    9394   tcfail179(normal) 
    9495}}} 
     
    108109 * tcfail071: VALID.  Now reports one instead of two errors as deferred unification is checked only after the contexts of mutually recursive groups have been unified.  (The latter is what this test case is really about, and it still works fine for that.) 
    109110 * tcfail076: VALID.  Same as tcfail065. 
    110  * ~~tcfail071~~: ?? Changed error message (has now only one of two parts).  Unsure whether the lack of the second part signals regress. 
    111111 * tcfail102: VALID. 
    112112 * tcfail103: VALID.  Error message is actually better! 
    113113 * ~~tcfail128~~: VALID. Same as tcfail046. 
    114114 * ~~tcfail145~~: VALID. Error message got worse. 
    115  * ~~tcfail153~~: VALID. Related to Simple5a in that a match against a rigid type variable gets reported as an equality context that could not be deduced. 
     115 * tcfail153: VALID.  Error message is different, but equally correct and accurate.  The type mismatch manifests itself at two different subexpressions.  Due to a different traversal order, we now report the error at the other subexpression. 
    116116 * tcfail179: VALID.  If anything, the error message improved. 
    117117 * while: VALID. Works if definition of `succeed` gets a type signature `Monad m => a -> m a`.  The error seems to be due to the new GADT rules about annotations, but the error message is a bit strange; ie, need to be improved. 
     
    120120 0. ~~Panic in case of ambiguous type variables (break001, break006, and print019).~~ 
    121121 0. Problem instantiating rank-2/impredicative types (tc210 & tc211). 
    122 }}}