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
In this commit we add nullability to upper type of a substituted
constraint in the situation like (Stub<_L> <: SomeType),
where _L is fixed to nullable Stub<_L>?.
We have to change this constraint to L <: SomeType? and not to
L <: SomeType as before, otherwise nullability become broken
(direct substitution of Stub<_L> to L is illegal here).
#KT-50470 Fixed
sebastian.sellmair