Previously,
* Equals performs IEEE 754 equality check for floating points and
byte-to-byte checks for other types, including references.
* Ieee754Equals performs IEEE 754 for primitive types
* TotalOrderEquals performs total order equals to all types, including
floating points.
Now it is simplified,
* Equals performs total order checks for all types.
* Ieee754Equals performs IEEE 754 for primitive types.
* (TotalOrderEquals is removed.)
Most of these tests used this directive as a way to opt in to a new
language feature, and most of those features are already stable for a
long time, so no opt-in is needed. Some other tests used the directive
to opt out from a language feature, replace those by the `LANGUAGE`
directive. One test used the directive to test behavior that actually
depended on the API version; use `API_VERSION` directive there instead.
This looked like a small and useful change, but caused so many issues
(KT-24474, KT-24790, 30b9caea, and another unreported one -- see the
test update in this commit) that it didn't pay off after all. The
optimization is not that critical for now, as it's only relevant for
data classes where component types have trivial equals/hashCode
implementation, which is not very often
#KT-12330 Declined
Synthesized 'copy' introduces default values for parameters, which is
prohibited for regular overrides.
Report warning in language version 1.2-, error in 1.3+.
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 prerequisites for generating equals/hashCode/toString in a data class:
previously they were generated if the corresponding method is trivial (i.e.
it comes from kotlin.Any), now we're generating it always unless it'll cause
a JVM signature clash error (see KT-6206)
- use static KotlinBuiltIns.isXxx methods to compare types instead of checking
against descriptors loaded from certain built-ins instance, this is quicker
and more correct in environments where several built-ins are possible
- don't use isOrOverridesSynthesized, it's not relevant for
equals/hashCode/toString because functions with these names are never
synthesized
#KT-6206 Fixed
Ting-Yuan Huang