summaryrefslogtreecommitdiff
path: root/test/files/lib/scalacheck.jar.desired.sha1
Commit message (Collapse)AuthorAgeFilesLines
* Fixed scalacheck tests.Paul Phillips2012-02-041-1/+1
|
* Workaround for scalacheck calling System.exit d...Paul Phillips2011-07-181-1/+1
| | | | | | | | | Workaround for scalacheck calling System.exit during testing. Not sure exactly what the sequence of events is here: I found the exit problem months ago and committed code to scalacheck to make that configurable, and then didn't see it again until recently, but I don't think it was ever addressed. This is just a bandaid. No review.
* Brought scalacheck up to date with scalacheck t...Paul Phillips2011-07-161-1/+1
| | | | | | Brought scalacheck up to date with scalacheck trunk (rev 06612e965d) and rebuilt jar against r25318, no review.
* introduce NullaryMethodType to disambiguate Pol...Adriaan Moors2011-01-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | introduce NullaryMethodType to disambiguate PolyType motivation: given `def foo[T]: (T, T)` and `type Foo[T] = (T, T)`, `foo.info` and `TypeRef(_, Foo, Nil).normalize` are both `PolyType(List(T), Pair[T, T])` uncurry has been relying on an ugly hack to distinguish these cases based on ad-hoc kind inference without this distinction, the type alias's info (a type function) would be transformed to `PolyType(List(T), MethodType(Nil, Pair[T, T]))` anonymous type functions are being used more often (see #2741, #4017, #4079, #3443, #3106), which makes a proper treatment of PolyTypes more pressing change to type representation: PolyType(Nil, tp) -> NullaryMethodType(tp) PolyType(tps, tp) -> PolyType(tps, NullaryMethodType(tp)) (if the polytype denoted a polymorphic nullary method) PolyType(Nil, tp) is now invalid the kind of a PolyType is * iff its resulttype is a NullaryMethodType or a MethodType (i.e., it's a polymorphic value) in all other cases a PolyType now denotes a type constructor NullaryMethodType is eliminated during uncurry pickling: for backwards compatibility, a NullaryMethodType(tp) is still pickled as a PolyType(Nil, tp), unpickling rewrites pre-2.9-pickled PolyTypes according to the expected kind of the unpickled type (similar to what we used to do in uncurry) a pickled PolyType(Nil, restpe) is unpickled to NullaryMethodType(restpe) a pickled PolyType(tps, restpe) is unpickled to PolyType(tps, NullaryMethodType(restpe)) when the type is expected to have kind * the rewrite probably isn't complete, but was validated by compiling against the old scalacheck jar (which has plenty of polymorphic nullary methods) nevertheless, this commit includes a new scalacheck jar summary of the refactoring: * PolyType(List(), tp) or PolyType(Nil, tp) or PolyType(parms, tp) if params.isEmpty ==> NullaryMethodType(tp) * whenever there was a case PolyType(tps, tp) (irrespective of tps isEmpty), now need to consider the case PolyType(tps, NullaryMethodType(tp)); just add a case NullaryMethodType(tp), since usually: - there already is a PolyType case that recurses on the result type, - the polytype case applied to empty and non-empty type parameter lists alike * tp.resultType, where tp was assumed to be a PolyType that represents a polymorphic nullary method type before, tp == PolyType(tps, res), now tp == PolyType(tps, NullaryMethodType(res)) * got bitten again (last time was dependent-method types refactoring) by a TypeMap not being the identity when dropNonConstraintAnnotations is true (despite having an identity apply method). Since asSeenFrom is skipped when isTrivial, the annotations aren't dropped. The cps plugin relies on asSeenFrom dropping these annotations for trivial types though. Therefore, NullaryMethodType pretends to never be trivial. Better fix(?) in AsSeenFromMap: `if(tp.isTrivial) dropNonContraintAnnotations(tp) else ...` TODO: scalap and eclipse review by odersky, rytz
* Added scalacheck tests for parallel collections.Aleksandar Pokopec2010-09-011-1/+1
| | | | | Review by phaller (not urgent).
* Rolled partest back to r21328.Paul Phillips2010-05-061-0/+1
changes necessary to plug it back in while preserving everything which has happened since then in tests and such, but we should be the lookout for overreversion. Review by phaller (but as a formality, I don't think it requires direct review.)