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
A module created for expression evaluation contains `fragment.kt`,
the file that contains necessary code for the expression
to be successfully evaluated (including the expression itself).
However, the IrFileImpl created for the fragment doesn't refer
to the module, leaving its lateinit `module` property uninitialized.
So, simply put, a parent has a child, but that child
doesn't have the parent. And that may lead to various errors.
Compose has a psi2ir lowering that transforms Composable declarations,
and for that it deep-copies all the declarations
(see `androidx.compose.compiler.plugins.kotlin.lower.
ComposerParamTransformer#lower`).
During the copying, it eventually tries to access that uninitialized
`module` property (`org.jetbrains.kotlin.ir.util.
DeepCopyIrTreeWithSymbols.visitFile`),
which predictably ends up with an exception.
The exception propagates down the stack, interrupting further
Compose lowerings, but eventually it gets swallowed at
`com.android.tools.compose.ComposePluginIrGenerationExtension#generate`.
So, fragment compilation continues and brings forth more complicated
errors on later stages, in particular during the codegen,
like in the IDEA-320738, when some declarations don't have
their lateinit `parent`s initialized.
This one example in the issue strikes during expect declarations
lowering at `org.jetbrains.kotlin.backend.common.lower.
ExpectDeclarationRemover.tryCopyDefaultArguments`.
The problem arisen in the issue could be solved on the Compose side,
but there's no telling what else can get broken because of
this module-file inconsistency.
Fixes IDEA-320738
Merge-request: KT-MR-10914
Merged-by: Alexander Kuznetsov <Aleksander.Kuznetsov@jetbrains.com>
Note that call-site class has no metadata for inlined local delegated
properties. Thus, for an inlined local delegated property we should
obtain declaration-site class as owner - otherwise, the corresponding
`PropertyReference` will have an owner without property metadata.
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.
This will help in some lowerings which need to change the callee of a
call. Instead of creating a new call and copying everything (type
arguments, value arguments, receivers, annotations, attributes, ...),
it's easier to modify the `symbol`. In a way, this is a continuation of
22b4b29292.
Similarly to how stub bodies are generated for functions in the kapt
mode (see `BodyGenerator.generateFunctionBody`).
This is more useful then not generating bodies at all, because otherwise
in the -Xjvm-default=all/all-compatibility modes it would be difficult
to differentiate functions with default implementations from the ones
without (because they all would lack body and thus be generated as
abstract into the resulting Java stub).
The effect of this change is pretty minor, so there's no YT issue. But
it fixes light analysis tests run with JVM_IR in
`codegen/box/jvm8/defaults`, because now there's no difference between
full analysis and light analysis for interfaces with default methods in
new modes.
IR inliner should evaluate `apiVersionIsAtLeast` on compile-time (except
cases of inlining to inline functions from kotlin runtime) just as
bytecode inliner does.
^KT-59291: Fixed
Dmitriy Novozhilov