It affects the `is IrGetField` check in
TypeOperatorLowering.computeNotNullAssertionText, which leads to missing
NPE messages when accessing backing fields of public properties.
#KT-64615
This was never semantically correct, but was not important
before KT-63644, as they were immediately dropped after that anyway.
After KT-63644, they were used to compute fake overrides inside them,
which were later matched against actual class, which can
produce false-positive matching errors.
^KT-64835
Replace every property with its getter and setter. This is needed
because later on, JVM backend assumes that all properties have been
lowered (by JvmPropertiesLowering) to this state.
#KT-64116 Fixed
Because of KT-64743 there is unexpanded type-alias in a place we don't
expect it to occur. To workaround this, we just expand typialiases in
one more place.
^KT-64743
We don't have true flexible types in the IR, but we approximate it with
internal type annotations, such as FlexibleNullability,
FlexibleMutability, RawType. These annotations are then handled
specially in JvmIrTypeSystemContext, which can construct a fake flexible
type so that type checker on IR types would behave exactly as on
frontend types.
As shown in KT-63441, one instance of flexible types where flexibility
was lost during conversion to IR is Java array/vararg types. It's
necessary to support it so that IR fake overrides could be constructed
correctly, because IR fake override checker requires parameter types to
be equal. So this change introduces another internal type annotation,
FlexibleArrayElementVariance, which is only applicable to types with
classifier kotlin/Array, and which signifies that the annotated type
`Array<X>` should rather be seen as `Array<X>..Array<out X>`.
#KT-63441 Fixed
#KT-63446 Fixed
This commit gets rid of the redundant typeApproximatorConfiguration
in Fir2IrTypeConverter and uses the type approximator for captured
types instead of the manual approximation used before.
This fixes the nullability of approximated captured types, which fixes
a runtime error in WASM.
This also brings K2 IR closer to K1 IR in one test.
#KT-64261 Fixed
Previously, we would ignore the candidate with the non-smartcasted
receiver if they have the same symbol.
Now we prefer them when they're visible or when the smart cast changes
the nullability.
This commit fixes two tests related to removed workaround of KT-59818,
and also makes processing suspend functions in J/K hierarchy more consistent.
Before this commit, when we had Java class "suspend" method
(implemented with the help of Continuation) overriding Kotlin suspend fun,
the Kotlin suspend fun was visible in outer use-site scope,
and the Java method was invisible.
Also, we used a special "Java suspend view" just to determine
that Java method overrides Kotlin suspend fun and no more.
After this commit, Java class "suspend" method will be visible
in this hierarchy and Kotlin suspend fun will not.
Also, the "suspend" is visible as a synthetic Kotlin suspend fun
which is more correct.
Related to KT-63233
#KT-59818 Fixed
We cannot skip resolution in the case of type actualization as we cannot
guaranty that there are no any classes in super types which can be
actualized in the current context
^KT-62832 Fixed
^KT-63547
```
interface A {
fun <T> foo(): T
}
class B(val a: A) : A by A {
generated fun <T'> foo(): T' {
return a.foo() // <------
}
}
```
There was a problem that type of generated delegated call used
an unsubstituted type of the original delegated declaration, which led
to a situation when (see example) type of call `a.foo()` was not `T'`
but `T`, which led to incorrect IR and further exceptions on backend
^KT-64257 Fixed
^KT-64284 Obsolete
After a generation of fake overrides some code may still to refer old
symbols from declaration storage (like computation of overridden
symbols for lazy functions), so we need to remap those symbols using
information from IR f/o generator
This change affects only mode with IR f/o generator
The old way of overridden computation with fir2ir f/o generator relied
on the fact that fir2ir generator creates IR for all f/o and fills
its caches. But with IR f/o generator enabled, we don't call fir2ir
generator, so some caches are missing. And for this mode it's enough
to acquire the symbol using the original declaration symbol and the
lookup tag of the corresponding supertype
Relates to KT-64202
There are a lot of restrictions between different parts of the pipeline.
1. Fake overrides can't be built before classes are actualized
2. Constants can't be evaluated before callables are actualized
3. Callables can't be actulaized before fake overrides are built
4. Checkers can't run before constants are evaluated
This commit reorders things to make all these restrictions happy.
^KT-63644
There are many complications with the current design of passing data
from within in-place lambdas to surrounding code. Solving these
complications will involve more time to investigation than is available
within the K2 release. So we are disabling passing type statement
information from lambdas for the time being until more time can be
devoted to a more complete solution.
^KT-60958 Fixed
^KT-63530 Fixed
The problem here is that for common session we register `FirJavaElementFinder`
which provides light classes based on expect classes. And then
at the start of analysis of jvm module we register one another
`FirJavaElementFinder`, which sees actual classes and uses them to
build light classes
But, because class ids of expect and actual class pair are the same and
element finders are ordered by creation order, when java resolve tries
to resolve some class, it founds light class based on expect class,
even if we are already in platform session
To fix this problem, it was decided to unregister all previous element
finders on creation of each new session, so old finders won't interfere
with analysis
^KT-63612 Fixed
^KT-64296
This particular test references kotlin.reflect.KProperty1 both in
common and platform sourceset. And if there is no stdlib in dependecies
it resolves to KProperty1 from builstins, which is expect (see KT-64061),
which leads to broken expectations that after IR actualization there
are no referenced expect classes
Denis.Zharkov