Some boolean expressions could be transformed into `IrWhen`
node. To understand that this node is actually
a boolean expression, we need to analyze its origin.
#KT-62683
IrStatementOriginImpl and IrDeclarationOriginImpl were made final
classes to simplify the creation of them (a delegate provider was
added) and to optimize performance when comparing the origins by type
and name
The hack involving disabling constant inlining via the inlineConstVal
flag was necessary to avoid a JS IR incremental compilation issue.
Since the issue has been fixed, the hack is no longer needed.
The diagnostics cannot be implemented with the FIR frontend checker
because it requires constant evaluation over FIR.
Therefore, the diagnostics are implemented as a set of klib checks over IR.
For the diagnostics, the js() call argument must be
evaluated and inlined as IrConst<String> into IR
in the same way as const val initializers and annotation arguments.
^KT-59388 Fixed
^KT-59399 Fixed
^KT-62425 Fixed
Split it to 4 functions for clarity: resolveFakeOverride,
resolveFakeOverrideOrFail, resolveFakeOverrideMaybeAbstract,
resolveFakeOverrideMaybeAbstractOrFail. Remove/inline duplicated
utilities and remove unused parameters.
In IR interpreter we have "preprocessors". Preprocessor is a
transformer that changes IR expressions in a way that we can
interpret them at least partially.
We have two places where interpretation is happening:
1. Right after fir2ir where we evaluate only strictly necessary
expression for `const val` and annotations.
2. In lowering for every backend where we are doing some
constant folding.
Earlier, to avoid double work, we didn't launch preprocessors
in backend if we were using K2. But this approach breaks compilation
for MPP projects where one module is compiled with K1 into klib
and the overall project is compiled with K2. On the backend side,
we are mistakenly assuming that preprocessors were launched, but they
were not.
The solution is to run preprocessors only on the backend side. If we
think about it, interpretation on fir2ir doesn't require any
preprocessing because we are working only with expressions that are
correct and must be fully evaluated.
#KT-62126 Fixed
Before const inlining for fields, we actually want to remember a given
field in `InlineConstTracker`. We are doing it already in const
evaluation. So we just need to ignore const inlining in
`CallAndReferenceGenerator` and delegate it to const evaluation.
#KT-60737
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.
vladislav.grechko