tree 17585d9a053e3409e7d7c9e0e2febd750677f822
parent 37c2c862d84fd20a6dc43bf7183b8d8c90d60d17
author Alexander Kuznetsov <aleksander.kuznetsov@jetbrains.com> 1688077677 +0200
committer Alexander Kuznetsov <aleksander.kuznetsov@jetbrains.com> 1688077677 +0200

[debugger] IrFile for KtBlockCodeFragment should have a module

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