In FIR we desugar when with multiple conditions leading to same block
as tree of OR expressions
Given
```
when(some) {
"a", "b", "c" -> {}
else -> {}
}
```
actually desugared into
```
when(val <subj> = some) {
<subj> == "a" || <subj> == "b" || <subj> == "c" -> {}
else -> {}
}
```
There is a multiple ways of how we can organize such expressions in FIR
Previously it was just nesting-chain of OR expressions
While the most efficient way in terms of required stack depth is
a balanced tree
KT-53255
After we added "careful approximation of contravariant projections" in
584b70719e, some SAM conversions started to require an additional
implicit cast of the functional value before it is converted to the SAM
interface. The target type of this implicit cast was computed
incorrectly because it didn't contain nullability of the SAM type. This
could lead to a situation where a nullable value was incorrectly cast to
a non-null type, which caused a missing null check and NPE at runtime.
For example, let's consider the test `kt54600.kt`. SAM conversion
happens in the constructor call `J(filter)`. Before 584b70719e, the IR
for that argument was (irrelevant things are omitted for simplicity):
TYPE_OP SAM_CONVERSION type=Condition<String!>!
GET_VAR filter type=Function1<String, Boolean>?
After 584b70719e, the IR became:
TYPE_OP SAM_CONVERSION type=Condition<Any?>!
TYPE_OP IMPLICIT_CAST type=Function1<Any?, Boolean>
GET_VAR filter type=Function1<String, Boolean>?
Note the two changes:
* The resulting SAM type changed from `Condition<String!>` to
`Condition<Any?>`. This is exactly the point of the "careful
approximation" change, because just erasing the "in" projection from
the parameter type is incorrect, see the explanation for that change.
* The value is now implicitly cast to the _non-null_ function type
before it is SAM-converted. The presence of the cast is fine, but the
fact that it's to a non-null type is an oversight.
The target type for this cast is computed at
`KotlinType.getSubstitutedFunctionTypeForSamType` in psi2ir. Now it
extracts the nullability from the SAM type and retains it in the
resulting function type.
After this change, the IR for the argument becomes:
TYPE_OP SAM_CONVERSION type=Condition<Any?>!
TYPE_OP IMPLICIT_CAST type=Function1<Any?, Boolean>!
GET_VAR filter type=Function1<String, Boolean>?
Note that the target type is now flexible, as the resulting SAM type.
Another option would be to make it nullable, as the type of the
functional value, but there doesn't seem to be any difference.
#KT-54600 Fixed
In 1.7.20 we used the nearest Java-based receiver for such field
references in backend. Now we are using use-site receiver again,
it can lead to accidental usage of derived class property backing field.
This is effectively a revert of KT-49507 fix, see commits:
- fa914f20
- b0a6508d
#KT-54393 Fixed
#KT-49507 Planned
#KT-52338 Planned
Since KT-53308, we started to cache results of typeOf invocation
in reflection. The cache uses the origin 'KClassifier' as a key with
an optional list of 'KTypeProjection' in type argument position,
and computed result as a value.
Without classifier check, the caching produces incorrect execution in
a very specific classloaders usage which is leveraged
by IDEA source-tree:
* All Kotlin stdlib and reflect classes are always loaded by the same
classloader
* Other classes that depend on Kotlin are loaded by separate
classloaders
The reproducer:
* Attempt to use typeOf<kotlin.List<Foo>> from one classloader caches
the resulting KType
* Attempt to use typeOf<kotlin.List<Foo>> from another classloader
for the same 'Foo' that differs only in classloader reuses the
computed KType, meaning that KType type argument classifier
is simply incorrect and points to the 'Foo' from the first classloader
#KT-54611 Fixed
#KT-54629 Fixed
Merge-request: KT-MR-7470
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
If string concatenation contains object value, then this argument
will not have explicit toString call. We must find and check toString
method manually.
#KT-54615
These should only have ever been necessary for field type inference in
coroutines, which should have been fixed by 0fc676a20c.
Unlike 903a5d69a4, this time the change is in an optimization pass.
Advantage: optimization passes have a closer to the JVM view of the
bytecode, which makes this change significantly more likely to be correct.
Disadvantage: technically we don't really guarantee optimization passes
other than FixStack will run at all. For KT-54581 this is 100% fine
since the problem itself is caused by redundant checkcast elimination in
the first place (otherwise there would've been a redundant cast to
String), but for KT-53146 this means the fix is somewhat incidental and
not necessarily guaranteed.
^KT-53146 Fixed
^KT-54581 Fixed
'equals' from any made available for overriding in inline classes
'typed' equals made available for definition in inline classes
'typed' equals definition made compulsory if 'untyped' is overridden
'operator' keyword is allowed in 'typed' equals definition
^KT-24874: Fixed
Igor Yakovlev