When we have some custom implementation of Comparable, it's important
that we compare values exactly as 'lowBound <= a && a <= highBound'.
Make sure that evaluation order and compareTo calls match for
optimized and non-optimized case.
As of Kotlin 1.0 and 1.1, expression 'a in x .. y' is considered
equivalent to 'x.rangeTo(y).a', and should be evaluated in the following
order:
1. x
2. y
3. a
4. compare x with a
5. compare y with a (if needed)
It's safe to upcast integer types to Long,
floating-point types to Double.
So we don't have to create a range instance for cases such as
fun testLongInInt(x: Long, a: Int, b: Int) =
x in a .. b
which is equivalent to
fun testLongInInt(x: Long, a: Int, b: Int) =
x in a.toLong() .. b.toLong()
Provide BoundedValue-based implementation of InExpressionGenerator,
test it on range of comparable values.
Drop unneeded test (range of comparables is already tested by
ranges/contains/inComparableRanges.kt).
There's a subtle difference in behavior between comparing
primitive Float/Double (comparison follows IEEE standard)
and boxed Float/Double (comparison is a total order).
Make sure this corner case is preserved.
This patch mutes the following test categories:
* Tests with java dependencies (System class,
java stdlib, jvm-oriented annotations etc).
* Coroutines tests.
* Reflection tests.
* Tests with an inheritance from the standard
collections.
Change expectations for double and float ranges according to #KT-4481
#KT-5044 #KT-4481
Custom 'rangeTo' might be unoptimized, but still 'in' should not diverge from 'contains'.
Dmitry Petrov