Don't mangled functions annotated with @JvmName.
Annotate 'Result.success' and 'Result.failure' with @JvmName and
@Suppress("INAPPLICABLE_JVM_NAME").
NB this would require bootstrap.
Otherwise, the generated bytecode is unnecessarily suboptimal in some
(arguably weird) cases.
In the JVM backend, this was an accidental regression in #3260, as I had
not noticed that effectively inline-only functions were handled by a
separate branch in FunctionCodegen. In JVM_IR, I'm pretty sure the
redundant markers have always been there as `isSuspensionPoint` in
ExpressionCodegen never checked for effectively-inline-only-ness.
If an inline class is mapped to a reference type (or an array), it's Ok
to treat JVM view on a suspend function as returning a value of
corresponding inline class (although in reality it returns 'Any?'
because of COROUTINE_SUSPENDED).
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.
We can only use IrStrinConcatentation to represent calls to Any?.toString
and toString calls on primitive types. Otherwise, x.toString() and "$x"
are observably different when x is a non-null type with null value
(e.g., an @NotNull value coming from Java).
templates and plus concatenations.
This is slightly more efficient and mirrors the behavior of the non-IR
backend for templates (but not for plus concatenations).
#KT-36638 Fixed
values within initializer blocks.
The issue occurs in code like this:
```
class C {
var b = true
init {
b = false // Missing PUTFIELD for this statement
}
}
```
Added a new statement origin for field initialization (at declaration)
instead of relying on `origin == null` in ExpressionCodegen to determine
whether to generate the initializations.
This was unintentionally broken in
d68a1898d0.
If a part of an 'if' condition is an inline function call, we need to insert the original condition line after it. Otherwise, the debugger will think it is inside the inline function implementation. Obviously, this breaks stepping – instead of the 'if' body, we go on stepping through the inline function.
This commit fixes 'KotlinSteppingTestGenerated.StepOver#testSoInlineLibFun' test.
The first change here is swapping the isCompatibility and hasJvmDefault
checks. Otherwise behavior could be different depending on -Xjvm-default
mode even for non-JvmDefault declarations, which makes little sense.
Another change is avoiding generating $default stubs for fake overrides
in interfaces, which replicates the behavior of the current backend.
(Note that this change also fixes the first problem on the newly added
tests, but the first change seems useful anyway.)
Alternatively, we could improve the lookup utilities and their usages to
always find the exact override of a symbol from
Collection/Iterable/CharSequence/etc, but since we need to load the
original symbol anyway in cases when the loop subject's type is a type
parameter, we might as well simplify everything and always reference the
original symbol.
Also improve exception message and removed unused declarations in
IrBackendUtils.kt.
This corresponds to the ABI generated by the old backend. Moreover, when
compiling the module 'ir.tree' with JVM IR (could not reproduce on a
small sample), this led to a codegen crash when trying to reassign
parameter value to the default stub, which is an error expression and
can't be generated by ExpressionCodegen.
Change the treatment of default implementations on interfaces in JVM
compatibility mode. Previously, the IR backend moved the actual
default implementation to the DefaultImpls class, and then bridged to
it from the interface default. The old backend did the reverse, at the
cost of an additional accessor, in order to gain better binary
compatibility properties. See #2612 for discussion.
The accessor needs to call a specific implementation, so must be
performed through an `invokespecial`. We trick the
SyntheticAccessorLowering into doing this for us, by marking the
bridging call as a super call. We do this in want of an explicit
`invokespecial` Ir Node.
InterfaceDefaultCallsPhase previously assumed the old behaviour of the
IR backend (that calls to default implementations, e.g. `foo$default`
should target `DefaultImpls.foo$default`). But now the bridge to
foo$default resides on `DefaultImpls` already, causing that pass to
create a recursive loop. We cut that loop with a simple check.
Dmitry Petrov