Previously, when a candidate was found with an applicability that is
better than the current best applicability, all previous candidates were
thrown away. Now we keep them, unless the new applicability is
successful. If no successful candidates are found, we fully resolve all
the unsuccessful ones and select the ones with the least bad
applicability. This improves diagnostics for unresolved calls.
#KT-57844 Fixed
Leaking of a reference (via publishing to binding trace) of not fully
initialized object could lead to unpredicted and unexpected NPEs
iff some exception (like PCE or InvalidPsiAccess) happens between
the publishing and initialization.
#KT-57514
#KT-56388
#KT-56364
Merge-request: KT-MR-10052
Merged-by: Vladimir Dolzhenko <Vladimir.Dolzhenko@jetbrains.com>
This will fix problems with declaration clash.
Otherwise, a designation path to the constructor of the second class
from the snippet
```
class A
class A
```
Will contain the first class instead of the second
Also, this is more performed than trying to find a segment of
a path by providers
^KT-58546 Fixed
Compiler plugins (AllOpen, for example) can modify the status of a
declaration, including visibility and modality. If we observe them
without enforcing STATUS resolve, we risk to see incorrect information,
which in turn can lead to false negatives/positives in
inspections/intentions.
Add test for light classes. See KT-58503 description for the explanation
how the initial problem was influencing Spring inspections from intellij
repository.
^KT-58503 Fixed
The code in IrTypeMapper was incorrectly translated from
KotlinTypeMapper during the development of JVM IR. The
`classDescriptor.hasBigArity` condition in KotlinTypeMapper was checking
if the class represents a function or a suspend function with big arity,
and the suspend function part was lost during conversion.
This resulted in incorrect generic signature being generated, which led
to malformed type exceptions from reflection, and compilation errors
from kapt stub generation.
Also, change a comment in irCodegenUtils to avoid confusion of numbered
function types (kotlin.jvm.functions.Function1, ...) with the big-arity
type kotlin.jvm.functions.FunctionN.
#KT-58375 Fixed
FixesKotlin/kotlinx.serialization#2294
If the serializable class contains itself as a property, and its serializer is not an object (for example, for a sealed class), in this case there is a race in the initialization of the serializer and child serializers.
To avoid this the serialization class should not cache its own serializer as a child.
Merge-request: KT-MR-10019
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
Add more opt-ins in Samples, tests and Benchmarks.
This is a follow-up to KT-MR-9788
Merge-request: KT-MR-9997
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
Kirill Rakhman