This way it is a little less "hacky". We are looking only for "data"
property, and as long as this property is declared in constructor, we
can safely assume we will get the correct one even if it is
renamed.
Drop excess call of `callStack.loadState(it)` when store state for
extension receiver. When we interpret lambda with extension receiver,
this receiver will be actually represented as a value parameter,
and it required some additional processing. Apparently, after all
interpreter's refactorings, this does not matter anymore and excess
call can be dropped.
In early prototypes of interpreter, it was easier to assume that
all classes from Java can be interpreted and fix something if not.
Check for Java declaration was done by checking that the package name is
starting with "java". But this is actually wrong and can lead to errors
when some code is declared in "java" something package, but is not from
Java stdlib.
#KT-60467 Fixed
This is important for IR lowerings like PolymorphicSignatureLowering
which are very sensitive about the correct types of expressions and
placement of coercions to Unit (KT-59218).
A boolean parameter to `insertImplicitCasts` is not the best solution to
ensure that coercion to Unit is added. The best solution would be to fix
the TODO and generate coercion to the block's type for the last
statement. But that will affect many other places and will need to be
done separately => KT-59781.
Code in IrInterpreter is uncommented to fix the FIR test
`compiler/testData/ir/interpreter/exceptions/tryFinally.kt`; otherwise
evaluation of the function `returnTryFinally` there crashes with
"NoSuchElementException: ArrayDeque is empty". No idea why this test
didn't fail for K1 though, since the created IR is exactly the same.
For some unknown reason this breaks WASM backend with K2, but not with
K1 => KT-59800.
Earlier we always allowed to interpret `IrGetObjectValue` because
this value is used in const val getter. But now we do a special
check for such getter avoiding visit of `IrGetObjectValue` node.
#KT-59775 Fixed
We need to transform call from `KFunction(N).name` to
`KFunction(N+1).name`. This way we keep IR correct and if something
goes wrong during interpretation, we still will have compilable code.
This commit suppose to fix three failing tests on Native aggregate
build:
1. `FirNativePartialLinkageTestGenerated.
testReferencingUnusableDeclarations`
2. `FirNativeCodegenBoxTestGenerated$Box$CallableReference$Bound.
testKCallableNameIntrinsic`
3. `FirNativeCodegenBoxTestNoPLGenerated$Box$CallableReference$Bound
.testKCallableNameIntrinsic`
We want to forbid expressions of type `Unsigned == Unsigned` or
similar. Working with unsigned numbers we can only inline them on the
call site or use in `String.plus` expression.
This commit fixes problem in test `unsignedTypesInAnnotations`. Here
interpreter thinks that expression `ONE_UINT != 1u` can be
evaluated, but fails to do it. This fail prevent us from inlining
`ONE_UINT` and on runtime we get error about missing getter.
Earlier this property would have been inlined by `ConstLowering`,
but we got rid of it.
It basically can be replaced with IR interpreter. The only half-hack
was required in `PropertyReferenceLowering`. Const interpreter is
running before it, so we can't optimize some calls on const
properties that appear after this lowering. Solution is to inline
constants manually during property reference lowering.
In this commit we have a lot of change in test data. This was caused
by the way where we evaluate constants. We split constant evaluation
into two distinct parts: only necessary evaluations for `fir2ir`
(like const val and annotations) and optimizations for lowering.
Now we don't do all constant evaluation on `fir2ir`, but IR
dump is executed after this phase, so test data changed.
#KT-58923
This way we achieve faster compilation time. We want to traverse
IR tree as little as possible. If we add new checker than the time
to evaluate constants basically doubles.
#KT-58923
We can interpret all const elements. It wasn't true on early
prototype phase because of some problems with unsigned numbers,
but right now it is correct to assume that all const are valid.
#KT-58923
The first one `IrConstExpressionTransformer` is responsible for
transforming ordinary expressions and the second one
`IrConstAnnotationTransformer` is responsible for annotations.
#KT-57812
These two functions apparently are represented in Kotlin as methods
of `kotlin.String`. Because of that we accidentally treated them as
builtins.
To also minimize such cases, added filtration by return type. We are
allowing to interpret only these functions that have primitive or
unsigned return type.
#KT-57028 Fixed
Ivan Kylchik