Previously, containingDeclarationSymbol for V was set to the outer class
BaseRoot, so its upper bounds was computed to the ones from TNested
at org.jetbrains.kotlin.fir.resolve.calls.CreateFreshTypeVariableSubstitutorStageKt.getTypeParameterFromExpandedClass
^KT-56706 Fixed
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
These declarations should not be visible to users (and therefore are not added to FIR),
but plugin itself can reference them in already compiled serializable classes,
and therefore they should be available in metadata:
- synthetic deserialization constructor
- static write$Self function
See also:
^KT-55885
If a synthetic prop clashes with a real property (e.g. @JvmField
property from parent Kotlin class), don't generate fake override for the
synthetic property. This fixes a CONFLICTING_INHERITED_JVM_DECLARATIONS
error in a mixed hierarchy.
^KT-56538 Fixed
When expected type is known, use it as expected type for branch bodies.
While it indeed becomes different from the usual select call resolution,
where expected type is applied only after completion starts,
it helps to support, e.g. callable references resolution just as powerful
as it was in K1.
Also, in some cases where diagnostics have been changed, they become
a bit more helpful since they are reported closer
to the problematic places
cannotCastToFunction.kt test has been removed because it relied
on the case erroneously supported by the hack removed from
the FirCallResolver in this commit.
^KT-45989 Fixed
^KT-55936 Fixed
^KT-56445 Fixed
^KT-54709 Related
^KT-55931 Related
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
These type parameters where used in function parameters,
but since suspendImpl is static function, it has no access
to class type parameters. Solution is to copy them to
the function itself.
#KT-55125 Fixed
This is needed to provide an ability to extend different kinds of
functional types
Also, cleanup and rename utilities related to functional types to avoid
possible confusions
This fixes "IllegalStateException: Fir2IrSimpleFunctionSymbol for
<paramName> is already bound" when creating a callable reference to a
synthetic property
^KT-56072 Fixed
Calling createIrEnumEntry lead to "IllegalStateException:
Fir2IrEnumEntrySymbol for [declaration] is already bound" when the
IrEnumEntry was already created previously, e.g. by an annotation call
referencing it.
^KT-54079 Fixed
- The fix for KT-55570 caused some backend tests to fail, because errors
are now correctly reported for simple classes and actual/expect in
the same module is not supported in FIR. See KT-55177.
- The commit also adds separate tests for K2. Unfortunately, these have
to be disabled for K1 because K1 then reports "expect without actual"
errors.
* [JVM_IR] Limit inner class attributes to types in class file
Inner class attributes should only be recorded for types that
are materialized in the result class file. In particular, we
should not emit inner classes attributes for types that appear
only in fake overrides. We do map these types to track the
fake overrides for JVM signature clashes but they are not
materialized in the class file.
^KT-56104 Fixed
* [JVM_IR] Consistently pass around materialized boolean in mapType.
Ilmir Usmanov