1. merge(null of type A, null of type B) = null of unknown type;
2. merge(null of type A, something of type B) = merge(unknown null, B).
^KT-52311 Fixed
All tests in this commit _pass_ to document existing behavior, but
this will change in a separate commit as we reflect desired behavior
in the test expectations.
This is somewhat suboptimal since this results in `::suspendInline`
generating 2 classes while `{ suspendInline() }` only creates 1, but
it's the best allowed by the existing hierarchy of classes in stdlib. At
least it works?
^KT-50832 Fixed
These tests don't work on JVM target 1.6 after 6d664bcd10 because we're
generating `Boolean.compare` which is only available since 1.8. (It is
not a big deal because JVM target 1.6 is prohibited for users now.)
It's incorrect to take the first parameter type from the expression
itself because it can be nullable if smart casts are used. And if it's
nullable, it's mapped to the wrapper type and calling
`comparisonOperandType` for it makes no sense. Instead, take the type
from the callee function, as it's guaranteed to be mapped to a JVM
primitive type.
E.g. in `test1` function in the added test, the problem was that the
dispatch receiver type of the call expression is `Double?`, which is
mapped to `java/lang/Double`, whereas we clearly wanted to obtain the
primitive `D` (double) type.
#KT-52163 Fixed
For negative case, throwing CCE, we already have the issue KT-8135
and dedicated tests:
* genericDelegateUncheckedCast1.kt
* genericDelegateUncheckedCast2.kt
Related issues: KT-8135 KT-39588 KT-48749 KT-49837
`$$forInline` functions do not pass through the state machine generator,
and optimizing `Ref`s before that changes how assignments inside lambdas
passed to `suspendCoroutine`, etc. behave: without a `Ref`, the
assignment is not reflected in the continuation object, so the variable
has old value on resumption.
These functions will be optimized later, after they are inlined
somewhere and the state machine is generated.
^KT-52198 Fixed
E.g. in `x + f()` where `f` is an inline lambda, the instructions for
`+` should have the line number of that expression (while previously
they instead had the line number of the last line of the lambda).
^KT-51738 Fixed
The body of the InlinedLocalFunctionDeclarationInstruction was
not copied. That confuses the information on the exceptional edge
with the information on the normal edge.
^KT-52131 Fixed
Anastasia.Shadrina