Collecting 'moduleInfo' is required for the old history-file-based
incremental compilation approach. And the way how it is being collected
violates Gradle project-isolation feature as it accesses all Kotlin
compile tasks from other Gradle subprojects.
When the new IC based on classpath snapshot is enabled, the plugin will
not collect 'moduleInfo' making it compatible with project isolation.
^KT-59826 Fixed
The header klib is supposed to only contain the public abi of the module
similar to jvm-abi-gen. It is intended to be used as a dependency for other
klib compilations instead of the full klib for compilation avoidance.
^KT-60807
This slightly simplifies code, but has no other immediate benefits. In
the future though, we may end up optimizing all ClassLoweringPass
JVM IR phases by making them traverse only one list of all classes in
the module, instead of traversing the whole IR tree each time.
trackFakeOverrideMethod in JvmSignatureClashDetector is modified to
ignore fake overrides to prevent duplicate tracking of such methods,
improving efficiency
Reporting it for `VIRTUAL_MEMBER_HIDDEN`
is ok, because `VIRTUAL_MEMBER_HIDDEN`
has always been an error, so we are
allowed to treat these as overrides
implicitly.
^KT-59408 Fixed
^KT-59419 Fixed
^KT-57076 Fixed
Originally it was named createModuleFragmentWithSignaturesIfNeeded, because
there was a counterpart `...WithoutSignatures`. Now that function has
gone and there is only one entrypoint left
If some function is not fake-override, then its type should be just
default type of containing class
For fake overrides the default type calculated in the following way:
1. Find first overridden function, which is not fake override
2. Take its containing class
3. Find supertype of current containing class with type constructor of
class from step 2
^KT-60252 Fixed
Previously it handled `FirResolvedNamedReference` and `FirThisReceiverReference`,
but the second one effectively was never passed to this function. It
happened because `FirThisReceiverReference` is present only in `FirThisReceiverExpression`,
which is processed separately in `Fir2IrVisitor.visitThisReceiverExpression`,
and its implementation don't call `toSymbolForCall`
This change uncovered the following problem in pipeline: we have a contract,
that all bodies will be generated after all fake overrides will be preprocessed.
But DataClassMembersGenerator generates bodies before f/o creation,
which leads to the problem, if data class has forward reference to some
class which was not processed before (because in this case generator
of `hashCode` function will try to reference f/o, which is not created yet,
which leads to `SymbolAlreadyBound` problem)
```
data class Some(val a: A) {
generated fun hashCode(): Int {
return a.hashCode() // (1) is not generated yet
}
}
class A {
fake-override fun hashCode(): Int // (1)
}
```
This problem will be fixed in the next commit
(related test is compiler/testData/codegen/box/ir/kt52677.kt)
^KT-60924
Yahor Berdnikau