JS scripting uses the old IR to JS transformer.
The new IR to JS transformer can not be used for
JS scripting out of the box. Patching the new transformer for
JS scripting is potentially dangerous and requires a lot of effort.
Dropping JS scripting and the old IR to JS transformer allows to
refactor and simplify JS BE codebase.
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
Make smart-casts non-transparent expression without delegation
to underlying FirQualifiedAccessExpression, as children delegation in
fir tree has unclear semantics
Remove two different kinds of tree nodes for smart-casts
There is no need to create honest object in case of such simple
calculation. Furthermore, it can be harmful if enum class has
non-constant initializer or property.
#KT-53480 Fixed
... and the corresponding type parameter has a non-trivial (i.e.
non-`Any?`) upper bound.
The best solution here would be to get rid of
`removeExternalProjections` completely, and just use the type of the
argument at the call site, but see KT-52428.
#KT-51868 Fixed
For FE 1.0, we just change super qualifier symbol to
base class, if it's possible.
For FIR, we introduce using of super qualifier symbols for
field accesses and repeat FE 1.0 behavior here.
#KT-49507 Fixed
Mikhail Glukhikh