Deprecation 'kotlin.coroutines' property and related
'kotlin.experimental.coroutines' extension DSL. These properties
are not doing anything since 1.5.0 release and has to be removed long
time ago.
^KT-50369 Fixed
Allows using different current Kotlin versions in benchmark.
For example, SNAPSHOT version when current branch is master and
dev version on CI build.
^KT-49921 In Progress
A project like OKIO might have a lot (~700) module-dependsOn-paths
Prior this commit `findActualForExpected` was called for all modules
in all said module-dependsOn-paths which resulted in several thousand
invocations.
The new approach is to call `findActualForExpected` only for known
leaf modules to find all reachable actuals. From there, the actuals
get associated with intermediate modules in this paths and reported
accordingly.
^KT-50156 Verification Pending
In KT-50198, Spock generates a method named `$spock_feature_0_0` which
is annotated with `org.spockframework.runtime.model.FeatureMetadata`.
The problem is that for some reason (probably a bug in Spock or some
kind of version mismatch), this annotation lacks value for the method
`dataVariableNames`, which has no default value.
If an annotation lacks a non-default value, it's OK for the JVM, but not
OK for Java reflection. Specifically, `Annotation.equals` for annotation
proxy classes created at runtime checks that values are equal for each
annotation method. If there's no value for some annotation method
without a default value, it fails with NPE.
kotlin-reflect used `Annotation.equals` in `ReflectJavaAnnotation`,
however there was no intention to perform structural equals on
annotations; equals/hashCode were implemented only to make stuff like
`LazyJavaAnnotations.annotationDescriptors` work, which is a hash map
where `JavaAnnotation` (`ReflectJavaAnnotation` in kotlin-reflect) is
the key.
This commit changes equals/hashCode to use identity instead, since this
is cheaper, and safer because of cases like the one described above.
This is also consistent with other implementations, e.g. PSI-based
`JavaAnnotationImpl` which naturally checks if the underlying PSI
elements are the same, without any kind of structural equality.
I'm not entirely sure why this appeared as a regression in 1.5.30, but
the most likely candidate is the signature enhancement refactoring,
after which we (supposedly) started to load more annotations on
declarations coming from Java, just in case they are annotated with some
nullability annotations.
No test added because to replicate the issue, we basically need to
generate an incorrect annotation proxy class _at runtime_, which is
difficult.
#KT-50198 Fixed
Roman Golyshev