See the relevant test at t/
estData/codegen/box/sam/contravariantIntersectionType.kt
After the previous commit, when generating a call for `doOnSuccess {}`,
we have a SAM type with removed projection Consumer<Any?>, while
real function type of the lambda is a bit different
(Function1<ConcreteType & ConcreteType2>).
While for me, that looks questionable, but in K1 it was effectively
resolved via the same implicit cast that on JVM is generated to an
INVOKEDYNAMIC that wraps initial function-typed value.
^KT-53552 Fixed
It would be more consistently to prohibit the behavior from the unmuted
test (see KT-52428), but it was decided to postpone the breaking change.
Unfortunately, it didn't work to make a test where for computing
star projections we would need to substitute other type parameters
because effectively, it's not allowed to have SAM conversion when
star projections/wildcard is based on a type parameter which bounds
use other type parameters.
^KT-53552 In progress
Beside some corner cases, it's already prohibited in K1 because
adaptation have a bit strange nature
(they don't represent any existing real function exactly)
^KT-55137 Fixed
In details, this commit changes the following:
- it converts FIR when without branches to empty IR block without when
- it doesn't drop empty else branches in when anymore
This feature is not needed because it is unconditionally disabled for K1
(because of not fully correct implementation) and unconditionally enabled
in K2 (K2 does not support old behavior)
^KT-38895
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
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
This only affects JVM IR, and this is similar to how this was done in
the old JVM backend in `CallBasedArgumentGenerator.generateVararg`.
#KT-52146 Fixed
- Huge refactoring for IC
- Update hash combination logic
- Introduce value class for IC hashes
- Calc md5 directly by function IR
- Split IC logic by classes
- Move JsIrLinkerLoader into separate file
- CacheUpdateStatus is a sealed class
- Render TYPE_PARAMETER reified flag
^KT-51081 Fixed
^KT-51084 Fixed
Incorrect `valueParameter` was passed to `generateValueArgument`, which
resulted in incorrect type being considered for generating suspend
conversion.
#KT-50949 Fixed
* Change 1.6 to 1.7 constants
* Fix SAFE_CALL_WILL_CHANGE_NULLABILITY for testData
* Change EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_WARNING to EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_ERROR
* Change NON_EXHAUSTIVE_WHEN_STATEMENT to NO_ELSE_IN_WHEN
* Fix testData for SafeCallsAreAlwaysNullable
* Change T -> T & Any in test dumps
* Change INVALID_CHARACTERS_NATIVE_WARNING -> INVALID_CHARACTERS_NATIVE_ERROR
* TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_WARNING -> TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_ERROR
Denis.Zharkov