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.
Take branching and method calls into account when finding the line
number of the continuation. If there is no line number before
branching instructions or method calls, the following code is
still on the line of the suspend call itself.
This fixes a couple of issues with incorrect line numbers for
multiple throws on the same line or multipe suspend calls on
the same line.
In addition, it avoids the need to spam the method node with
repeated line number instructions in the IR backend.
In constructor stubs for default arguments, a marker parameter used
to have a non-null type, but null was passed as the corresponding
argument. This patch corrects the type.
When creating delegation redirectors for default implementations of
interface functions, `overriddenSymbols` should be repaired across the
whole module, not just a particular file.
Do this by reordering the lowerings so that the lowering that
adds continuations happen after default methods have been
eliminated if needed.
Mark more functions as known to be tail-calls: bridges and
delegated members.
Preserve source info and annotations when creating replacement
functions.
Given the strict pattern-matching in the inliner, this is the only way
to make it not crash when attempting to inline these stubs. Note that
the IR backend does not currently use the inliner's default method stub
handling; the crash only occurs when a module compiled with the non-IR
JVM backend is attempting to call an inline function with default
arguments defined in a module that was compiled with the IR backend.
If "null" was the first entry in an optimizable "when" over enum,
mapRuntimeEnumEntry was called before mapConstEnumEntry, and the
$WhenMappings field was not created. Now both mapConstEnumEntry and
mapRuntimeEnumEntry create this field on the first access
other than randomly throw assertion errors on inline calls in synthetic
functions, which have no line number attached.
`lazySourceMapper.callSiteMarker` is set in `InlineCodegen.inlineCall`;
`IrSourceCompilerForInline.doCreateMethodNodeFromSource` does not need
to touch it.
The challenge for overridable suspend functions is that the calling
the state machine method to resume after suspension would be
virtually dispatced to the wrong method. To avoid that a static
suspend implementation method is generated which becomes the
state machine method used to resume.
NOTE: jvmCrossinlineLambdaDeclarationSite.kt is muted because the
inliner does not remap references to an anonymous object's parent
class after regenerating it. Unlike the JVM backend, JVM_IR uses the
top level named class' assertion status for all inner classes. (The
test used to pass because the lambda in `inline fun call` read the
`$assertionsDisabled` field of `CrossinlineLambdaContainer`, which
was not reloaded after changing the assertion status of package `test`.)
This commit:
- introduces tests explicating what is and isn't considered a
proper main method on the JVM backends.
- implements support for parameterless main methods on the JVM IR
backend
- See KT-34338 for more tests.
suspend functions and lambdas.
Otherwise, when state-machine builder splits instructions and adds
LINENUMBER between states, the information becomes corrupted.
Ilya Matveev