Consider a file with only private top-level properties compiled into
a klib. If this klib is deserialized with deserializationStrategy.ALL
(e.g. if this library if passed using the -Xinclude flag),
initializers of these properties will not be generated in a final
binary.
This patch fixes this error by unconditionally adding IrFiles into
deserialization queue if deserializationStrategy.ALL is specified.
Issue #KT-34722 fixed
Top-level initializers must be deserialized in the same order they
where in the original source file. Before this patch this rule might
be violated. Consider the following case:
// lib1.kt
val a = 5
val b = a * 5
// lib2.kt
fun foo() = println(b)
Compile both files into libraries and then link an application
against them. During deserialization of lib2 'b' will be added
to the deserialization queue of lib1. After that we will add 'a'
to this queue too. Thus 'b' and 'a' will be in a wrong order
in this queue resulting in a wrong order of corresponding
top-level initializers in a final executable.
This patch fixes this issue by adding all top-level initializers
to a deserialization queue before all other declarations.
These changes allow us to accurately distinguish between statements and
expressions in the IR.
This also fixes the types of non-exhaustive conditional statements.
We should only insert a return statement at the end of a lambda or
function if the final statement is used as an expression (slice
USED_AS_RESULT_OF_LAMBDA and USED_AS_EXPRESSION).
- Added tests to demonstrate broken behaviour: the interaction of inline
functions and callable references with varargs and defaults in various
combinations.
- Refactored InlineCallableReferencesToLambdaPhase to look like and use
some of the infrastructure from CallableReferenceLowering.
- Lifted some of this infrastructure out to be broadly reusable.
Dmitry Petrov