This is already the case for straightline code such as
```
inline fun <R> f(size: Int, block: () -> R): R {
var result: R
result = block()
return result
}
```
However, if the local variable introduction happens at a merge
point as in the following example, we allow the unboxing but
only do it halfway. The initialization of the local is still
done with a null value.
```
inline fun <R> f(size: Int, block: () -> R): R {
var result: R
while (true) {
result = block()
if (size == 0) break
}
return result
}
```
This change disallows unboxing for this move complicated
case as well by bailing out if a local use is with a
TaintedBoxedValue (merge of Object and Integer).
^KT-48394 Fixed.
Before this commit we considered !isOverride as a sign that
function / field / accessor has no overridden symbols.
However, it's false for deserialized, because isOverride
is always false there.
This commit fixes 68 BB tests but breaks 25 BB tests (not yet muted)
Library methods such as 'listOf' are resolved
to have the package fragments as their parents,
but JVM expects their containing file classes as parents.
This fix generates those file classes and
uses them as parent replacements for such library methods.
* Move FinallyBlockLowering to common part
* Fix catching of dynamic exception
* Fix bridges for suspend functions
* Disable explicit cast to Unit
* Run lowering per module
* Update some test data
Support Comparable#compareTo for boxed primitive in redundant
boxing/unboxing analysis, along with CHECKCAST to java.lang.Comparable.
Note that we can do that for Float and Double, too, because
Float#compareTo(Float) and Double#compareTo(Double) are delegated to
Float#compare(float, float) and Double#compare(double, double),
respectively.
Fuse specialized comparison for integers with conditional jumps
if possible (both for Comparable#compareTo and Intrinsics#areEqual).
#KT-11959 Fixed
Allow kotlin.jvm.internal.Intrinsics#areEqual for boxed values.
Rewrite to primitive equality.
NB we can't do that for Float and Double, because java.lang.Float#equals
and java.lang.Double#equals behave differently from primitive equality comparisons.
Svyatoslav Kuzmich