We drop Kotlin function 'remove' or 'getOrDefault' from JvmMappedScope,
if it has platform-dependent annotation, and the bound Java class scope
does not contain a function with the same signature.
#KT-57268 Fixed
NB: in order to produce correct IR origins, the source element kinds for
some FIR elements has been changed. As a side effect, mapping PSI to FIR
slightly changed: namely, for `a[b]++`, `a[b]` used to be mapped on
`set` call or callable reference, but now it is mapped on `get` call.
^KT-61891: Fixed
^KT-64387: Fixed
Substitution of type arguments to non-reified type parameters may lead
to accidental reification, which should not be done (see ^KT-60174 for
examples). So, we should erase them, except the few cases.
^KT-60174: Fixed
^KT-60175: Fixed
Motivation of using dispatch receiver type when calculating method owner
was discussed here: https://github.com/JetBrains/kotlin/pull/3054
However, this is incompatible with type erasure of non-reified type
parameters on inlining (which will be done in future). Consider the
code:
```
inline fun <T> f(arr: Array<T>, p: (T) -> Int): Int = p(arr[0])
fun box() = f(arrayOf("abacaba"), String::length)
```
After inlining and erasure, the type of `arr[0]` is `Any`. Thus, when
calculating owner of `String::length` we would have `Any` instead of
`String` if we used dispatch receiver type.
Note, that this change affects bytecode instruction that invokes
method, but does not change which method is being invoked.
- For synthetic calls
- For delegated constructor calls
Also, I checked that for each toResolvedReference() (beside annotations)
that converts candidate to the resolved reference,
we run `runPCLARelatedTasksForCandidate()` in the same context.
^KT-65103 Fixed
Previously, when an Objective-C library had an unused Objective-C
forward declaration (`@class` or `@protocol`), cinterop tool didn't
include it into the resulting klib at all.
This led to a subtle bug (KT-64105). One Obj-C library has unused
Obj-C forward declaration, and another one depends on the first and
uses this forward declaration, e.g. as a function result type.
When building the first cinterop klib, this forward declaration is not
added to `includedForwardDeclarations` in the klib manifest (the
compiler uses this property to decide whether to synthesize the
corresponding class).
When building the second cinterop klib, the forward declaration is not
added to its manifest either, because it is located in the dependency
(and therefore should've been included there).
As a result, the forward declaration is included nowhere, and any
attempt to use it in Kotlin fails, including calling the function from
the second lib.
This commit fixes this bug by including even unused Objective-C forward
declarations, which is consistent with any other kind of declarations
and seems more natural.
^KT-64105 Fixed
In more details, we use either platform override checker (if we came
from platform) or the combined intersection scope override checker
at this place. Also this commit fixes various places around
JavaOverrideChecker, allowing to apply it in intersection override
checker properly:
- don't consider return types in this place
- apply JavaOverrideChecker if at least one candidate is from Java
- compare type primitivity closer to K1 logic
#KT-62554 Fixed
Partially fixes KT-63242
The primary constructor of a class needs to be the first subgraph of the
class control-flow graph. Based on the Kotlin specification, class
initialization order goes first primary constructor, in-place
declarations (properties and init blocks), and then secondary
constructors. If the class doesn't have a primary constructor, then it
is just skipped in the order.
Unfortunately, the class control-flow graph had in-place declarations
first and then all constructors. Instead, we should treat the primary
constructor as the first in-place declaration, and then continue with
the existing processing as secondary constructors. This will guarantee
that super constructor calls have the correct property initialization
information.
^KT-65093 Fixed
This is required for EnhancedTypeForWarningAttribute because scopes
should not be reused between cone types with different values of
this attribute.
#KT-63208
(cherry picked from commit 9189154cae)
For some reason, codegen box test was not added in 082c337faa. The main
point of it now is to check that everything works correctly in the
IrFakeOverrideBuilder mode.
This fixes some type argument mismatch errors caused by a captured type
being approximated and then captured again.
Some places need to be adapted to work with captured types that
previously only worked with approximated types.
#KT-62959 Fixed
Mikhail Glukhikh