There used to be code that extended a previous range instead.
However, that does not work as that extension could have the
local cover code where it does not exists. Since we no longer
extend the range of locals, we should always introduce a new
one even if there was another one for a previous range.
This filters it out for use in SAM wrapper generation with
invoke-dynamic.
The intrinsic is not actually used for code generation so
it is added to the list of intrinsics that should have been
lowered away before codegen.
^KT-45779 Fixed
CoroutineTransformermethodVisitor attempts to extend the ranges
of local variables in various situations. Probably in an attempt
to give a better debugging experience. However, all of these
range extensions lead to invalid local variable tables where
something is in the local variable table where nothing is in the
corresponding slot.
The code that extends variables to the next suspension point
instead of ending them when they are no longer live has issues
with loops. When resuming and reentering the loop, the locals
table will mention a local that we did not spill and which
is therefore not restored when resuming.
The code that extends local variable table entries if there
are no suspension points between two entries doesn't work
for code such as:
```
var s: String
if (suspendHere() == "OK") {
s = "OK"
} else {
s = "FAIL"
}
```
If the local variable ranges are collapsed into one, one of
the branches will have the local defined in the local variable
table before the slot is initialized.
FunctionNVarargBridgeLowering checked the name of the method instead
of whether the method overrides an invoke method. That doesn't work
when the name of the function gets mangled because of inline class
arguments.
Fixed KT-45084.
For code such as:
```
try {
var y = "y"
for (i in 0 until 1) {
return y
}
} finally {
println("finally")
}
```
The local variables `y` and `i` ended up covering the finally block as
well in the debugger.
This change splits the range of the locals so that they do
not cover the finally block.
This change does not change the inliner to do similar transformations,
so the range of locals is still wrong win finally blocks when inlined
into an inline function. Added a failing test to that effect.
The coroutine transformation would leave locals in the local
variable table across the code that reloads local variables from
the continuation on reentry. However, when reentering the function
the local has no value until after the reloads from the
continuation.
This change splits the locals in the local variable table to
avoid such uninitialized locals. A local alive across a
suspension point has its range split in two. One that goes
from the original start to the state label for the restart
after the suspension. The other goes from after the local
has been reloaded from the continuation until the previous
end of the local.
Coroutine transform would occasionally *extend* the range of a
local instead of shrinking it (if the next suspension point
is after the end point for the local). That leads to the local
variable table having a local that covers code where it is not
defined. That is invalid and leads to D8 removing the locals
table from the code.
When a suspension point is inlined, the inlining local spans
unspilling code where the local slot has not been initialized.
The transformer already inserted initialization code for the local,
however, it did not split the local variable table. Therefore,
the inlining local is defined on instructions where the local
slot has no value (namely the instructions that initialize
the local slot on the unspilling path).
This change adds splitting of the local variable table as well.
When updating to a new version of D8, the uninitialized local
slot showed up. D8 will repair it in this case, but it is
better to not generate such code.
This breaks from the loop itself which is inconsistent with
what happens for breaks in while conditions.
Also, the frontend will report that code after the loop is
unreachable, which it isn't. :-\
However, those issues are covered in
https://youtrack.jetbrains.com/issue/KT-17728, so for now
we follow the old backend to not "break" anyone. :)
Fixes KT-44412
FIR translates:
```
when (x) {
1, 2, 3 -> action
else -> other_action
}
```
to an IR structure with nested ors:
```
if ((x == 1 || x == 2) || (x == 3)) action
else other_action
```
This change allows that to turn into switch instructions in the
JVM backend.
Super-qualifiers have to be taken into account. Otherwise, too
few accessibility bridges will be generated which can lead to
binary compatibility issues.
This gives us more precise type information and can enable backend
optimizations. This was motivated by when expressions not compiled
to table switches in the JVM_IR backend.
Fixed KT-36845.
This make native compatible with change to remove default arguments
for these in the kotlin repo where they were confused.
(cherry picked from commit 706d0d2f618b53fb0d6cce433c65c6523aaf7591)
The current backend uses direct field access to the backing field
instead of calling the companion object accessor, which calls
an accessibility bridge, which then gets the field for code such as:
```
class A {
companion object {
val s: String = "OK"
}
// f uses direct access to the A.s backing field.
fun f() = s
}
```
This change does the same for the IR backend.
If we do, the local variable table will not make sense. As as
example:
```
inline fun foo(getString: () -> String = { "OK" }) {
println(getString())
}
inline fun bar() {
}
fun main() {
bar()
foo()
}
```
leads to the following bytecode:
```
public static final void main();
descriptor: ()V
flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
Code:
stack=2, locals=4, args_size=0
0: iconst_0
1: istore_0
2: nop
3: nop
4: iconst_0
5: istore_1
6: nop
7: ldc #53 // String OK
9: astore_2
10: iconst_0
11: istore_3
12: getstatic #30 // Field java/lang/System.out:Ljava/io/PrintStream;
15: aload_2
16: invokevirtual #36 // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
19: nop
20: return
LineNumberTable:
line 9: 0
line 13: 2
line 10: 3
line 14: 4
line 15: 6
line 16: 7
line 17: 19
line 11: 20
LocalVariableTable:
Start Length Slot Name Signature
2 1 0 $i$f$bar I
6 14 1 $i$f$foo I
4 16 0 getString$iv Lkotlin/jvm/functions/Function0;
```
The `getString$iv` local should not be there. It has been inlined away.
Leaving it in the local variable table leads to inconsistent locals
info. Local 0 contains an int but we declare a local of type
Function0.
Do not destructively update the @JvmStatic function, instead
create a copy on first access, and replace the original with
the copy in the jvm static lowering. This ensures that the original
function is seen in other lowerings independently of file lowering
order.
When calling vararg methods with a generic vararg type without
passing explicit parameters, we have to allocate an empty array
of the right type. We failed to do so previously, as we did
not take the type arguments for the dispatch receiver into
account.
The old backend makes bridges for protected and package-private
methods public. Also, for bridges for vararg methods, the vararg
marker is not on the bridge.
These differences seem minor but are visible via reflection, so
we might as well follow the old backend.
The MethodSignatureMapper expected to be able to look at the body
of the default argument stub. That is of course not possible when
it is from an external dependency.
Instead, we go through the attribute owner to get to the method
the stub is a default argument adapter for.
Use it to check that only the value parameters that are explicitly
marked assignable are assigned.
Currently, the only parameters marked assignable are those for
default argument stubs.
This allows kotlin-native to generate code in debug mode.
LLVM requires debug attributes for this code and SYNTHETIC_OFFSET
makes kotlin-native generate dummy debug attributes.
The generated bridges now have line numbers as for the JVM
backend. There are some extra (irrelevant) labels in the JVM_IR
bytecode listing compared to JVM so expectations can still not
be shared even though they are closer.
The current backend does that for some bridges. We do it consistently
for all bridges.
The line number used differs. For the JVM_IR backend, we use the
line number of the class to which the bridge is added. For the
JVM backend, that does not appear to be the case for bridges
in lambdas. I prefer the line number for a lambda invoke bridge
to be the line for the lambda instead os some surrounding class.
Loads of temporary variables that contain constants are replaced
with a copy of the constant. This avoids locals loads and stores.
However, the copy of the constant needs to have the offset of
the load and not of the original constant.
Fixes KT-41963.
This fixes smart step into for delegated member functions.
Additionally, we align on the string "memberFunctionName(...)"
for expression non-null checks for both JVM_IR and JVM
backends.
The difference is that JVM_IR generates line numbers for the
constructor field initialization.
In this case:
```
29: class B {
30: // comment
31: val bPropVal: Int,
32: // comment
33: var bProbVar: Int
34: ) {
```
the line numbers for the field initializations are 31 and 33 where
in the current backend the whole constructor has line number 29.
This allows compiler plugins such as Compose to do custom
default argument handling in methods that do not have origin
`FUNCTION_FOR_DEFAULT_PARAMETER`.
The code still bails out early is there is not defaults
mask, so there should be no compile-time penalty.
JVM_IR has consistent stepping behavior for secondary constructors
and init blocks. This change fixes the expectations for tests that
expect the less consistent JVM backend behavior.
Temporary variable loads in when expressions had the offsets
of the variable declaration. That leads to hacks during codegen
for line number generation.
Instead of those hacks, give the variable loads the offsets of
the context in which they occur. That avoids the codegen hacks
and fixes stepping behavior for more when expressions.
In addition, made the stepping information for constructor calls
consistent across JVM_IR and JVM. For JVM_IR that stepping behavior
is consistent for enum constructor calls in <clinit> for JVM it
is not.
In particular, the current line numbers could lead to stepping
into the catch handler even when the code in the try did not
throw an exception.
This was caused by the code materializing the final value having
the catch line number. This patch delays the materialization
until the line number of the usage has been emitted.
These line number tests only tested that a set of line numbers where
present in the java bytecode. Not that they would be hit in the
right order by the debugger. Moving them to stepping tests fixes that.
This exposes a couple of issues (in particular around try-catch-finally)
that should be fixed.
A number of tests are marked as failing now. Will investigate and
work on fixes next.
comparisons.
Having those conversions leads to unnecesary boxing and null checks.
This change does it only for JVM in the optimization lowering. It
is unclear to me if the other backends can get away with something
similar.
This allows removing a hack in the MethodSignatureMapper.
When introducing non-getter methods that dispatch to a getter
we have to be careful to use the right name.
DeepCopyIrTreeWithSymbols should create the link between new
properties and their new getter/setter.
Specifically, this commit improves the stepping behavior of the IR
backend around functions with defaults.
- Improved line numbers in the default handler itself for better
stepping when inlined.
- Improved source information on default arguments
- Improved test coverage of stepping behavior in old and IR backends.
Improves the stepping behaviour around inline methods with default
arguments. In particular, we now accurately step through the
evaluation of default arguments, but do _not_ spuriously show the exit
from the $default handler.
Fix line number generation for assignments where the right-hand
side of the assignment is not on the same line.
Fix line number generation for intrinsics functions where the
function is not on the same line as the last argument.
Be careful to not break stepping behavior with the iinc
optimizations.
The JVM IR backend code seems saner to me. The string concatenation
lowering for JVM IR calls the stringPlus intrinsic if there are
only two arguments. That leads to a lot less code:
```
load string
load argument
box argument
call Intrinsics.stringPlus
```
instead of
```
allocate StringBuilder
call StringBuilder.<init>
load string
call StringBuilder.append
load argument
call StringBuilder.append
call StringBuilder.toString
```
This will lead to more boxing, but a lot smaller code. We still
use StringBuilders in JVM IR if there are more than two strings
being concatenated.
Now that suspend function views are created in
AddContinuationLowering, we can let the
FunctionNVarargBridgeLowering deal with rewriting of large
arity FunctionN/SuspendFunctionN.
Mads Ager