The problem was that in K2 for some top-level script declarations we
need to add a dispatch receiver parameter (because frontend do not
assign any, but representing script as a class requires it to be the
script class) and at the same time, calls to these declarations rely on
properly set dispatch receiver parameter.
The simplest solution found is to have an additional traversal on the
relevan top-level declarations and assigning the dispatch receiver,
before running the main transformation.
#KT-64502 fixed
The previous one was incorrect for K1 since parent of top-level function
is `IrClass`, not `IrPackageFragment`.
The change is non-functional, K1 still worked correctly, but had to do
some extra work when inlining `emptyArray` calls and produces less
performant bytecode.
- remove ENABLE/COMPATIBILITY because they can no longer be used
- remove forAllMethodsWithBody because its behavior is now equivalent to
isEnabled
- inline isCompatibility
- inline DEFAULT
- rename ALL_INCOMPATIBLE -> ALL
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.
Affects IR Evaluator in IDEA.
The problem is happening because
`ReflectiveAccessLowering#fieldLocationAndReceiver` returns the class
the field was called on, not the class the field was declared in.
Then the class is used for obtaining a field by using reflection's
`getDeclaredField` to make the field accessible after.
But `getDeclaredField` doesn't work for field declared in a superclass,
hence the error.
#KT-65012 fixed
Merge-request: KT-MR-13919
Merged-by: Alexander Kuznetsov <Aleksander.Kuznetsov@jetbrains.com>
This is an addition to the f5bb477459
commit. Earlier, some of the validation checks were moved from
`stickyPostconditions` into separate lowering. But these
post-conditions checks were launched only when several flags were
set to true. In this commit, we just return to such behavior.
#KT-64116
It affects the `is IrGetField` check in
TypeOperatorLowering.computeNotNullAssertionText, which leads to missing
NPE messages when accessing backing fields of public properties.
#KT-64615
Replace every property with its getter and setter. This is needed
because later on, JVM backend assumes that all properties have been
lowered (by JvmPropertiesLowering) to this state.
#KT-64116 Fixed
We don't have true flexible types in the IR, but we approximate it with
internal type annotations, such as FlexibleNullability,
FlexibleMutability, RawType. These annotations are then handled
specially in JvmIrTypeSystemContext, which can construct a fake flexible
type so that type checker on IR types would behave exactly as on
frontend types.
As shown in KT-63441, one instance of flexible types where flexibility
was lost during conversion to IR is Java array/vararg types. It's
necessary to support it so that IR fake overrides could be constructed
correctly, because IR fake override checker requires parameter types to
be equal. So this change introduces another internal type annotation,
FlexibleArrayElementVariance, which is only applicable to types with
classifier kotlin/Array, and which signifies that the annotated type
`Array<X>` should rather be seen as `Array<X>..Array<out X>`.
#KT-63441 Fixed
#KT-63446 Fixed
Otherwise, if complex expressions such as when expressions are
used in combination with the intrinsics we get incorrect stepping
behavior.
^KT-64341 Fixed
This problem is extensively described in
`cadbc87dfd1ce3e63481ab90874ca8858878c55f` commit message.
TLDR: compiler is also called from Android LiveEdit plugin where
we want to be able to use compiler plugins. For that reason, we have two
different flags in the compiler. One is only for "evaluate expression"
(`doNotLoadDependencyModuleHeaders`) and the other for both LiveEdit
plugin and "evaluate expression" (`shouldStubAndNotLinkUnboundSymbols)`.
We want to forbid using compiler extensions for "evaluate expression"
and allow for LiveEdit plugin.
#KT-63695
Nikita Nazarov