Fixes KT-50992
DeclarationDescriptor.isInlineClass misidentifies inline classes without
constructors. This can happen for the ABI of inline classes with private
constructors.
Implicit receiver type inside expect class is inconsistent with the
type resolved from an explicit reference inside that class. The former
one is a default class type, i.e. expect; the latter one resolves to
an actual type when either expect and actual are in the same module, or
when the sources are compiled for a particular platform.
The workaround is to manually actualize implicit receiver type for one
particular check affected by the broken subtyping.
KT-49714
This is much more correct, because we have one to one mapping for
special java functions in this case, so using single nullable name
instead of list of names makes code more readable
Please read the description of IDEAPluginsCompatibilityAPI.
Also, you may notice, that Deprecation annotation was removed.
That is because with level ERROR it isn't possible to opt-in
to such API in the legit cases. And with level WARNING it won't be
reported because We have diagnostic with level ERROR about OptIn marker.
Sadly, there is no way to add ReplaceWith to the OptIn marker
Mostly, it only affects FIR
It partially allows to consider several variance of constraints like
A<Int> & A<T> <: A<X_var> that are mostly brought by smart casts
^KT-49542 Fixed
^KT-50489 Relates
This is a partial revert of e857966edb.
Specifically, behavior is restored in the old backend, which will allow
to support language version 1.3, where this language feature was not
enabled yet. There are no changes in the JVM IR backend, because to
enable JVM IR with LV 1.3, you need to pass the compiler argument
`-Xuse-ir` which is not stable and we don't guarantee anything about it.
#KT-50251
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
Ilmir Usmanov