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.
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
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.
The number of initializations of the `value` field before the live range
begins does not really matter so long as we insert a write of a default
value to the local if there were none.
See KT-36812. Aside from the problem stated there, D8 will throw out the
entire LVT if it sees a variable that has not been written to (and will
generate incorrect SSA if the slot is reused with a different type).
Note: this only fixes a FIR test because it's missing an `else -> throw`
branch, and default initialization satisfies the verifier and masks the
incorrect control flow.
