ATM unconditional `resolvedStatus` call in `modality` causes a
performance degradation in our completion tests
Since `resolvedStatus` is called to make sure that all the
status-transforming compiler plugins had finished their job, it doesn't
make sense to call `resolvedStatus` if there are no such compiler
plugins registered
N.B. After KT-56551 is fixed, this optimization might become obsolete
and can be removed if proved so
This commit adds missing pieces for the puzzle:
Annotation instantiation feature uses IrProperty's initializer to instantiate
properties from other modules that have default values which weren't
specified on call site.
To support this feature properly, Fir2IrVisitor should fill LazyIrProperty's
backing field initializer with information from Fir.
To get this information into Fir, FirMemberDeserializer should be able to read
it from KotlinJvmBinaryClass with AnnotationLoaderVisitorImpl. (klibs are unsupported for now)
There's a catch with enum entries references: we can't access session.SymbolProvider to resolve it
because we're still at the deserialization stage, and it can cause StackOverflow if enum is nested in the
same class (see RequiresOptIn.Level). To mitigate this, a new FirEnumEntryDeserializedAccessExpression is produced
instead; it is later replaced with the correct reference in the Fir2IrVisitor.
^KT-58137 Fixed
Also add test to loadJava folder with annotations default values that
verifies metadata loading
`staticCFunction` is used a few times in this module, and it uses
kotlin-reflect to inspect the lambda parameter, which is only possible
for class-generated lambdas.
This is needed to enable indy lambdas in the project.
^KT-58587 Fixed
Review: https://jetbrains.team/p/kt/reviews/10136
This commit is important in scope of KT-57553. It makes the migration
more smooth.
Other related tests:
- testUninitializedOrReassignedVariables
- testAugmentedAssignmentInInitializer
The customization was added for compatibility with Gradle. That isn't a problem anymore, as we don't use it from KGP and soon we will eliminate the direct dependency on kotlin-compiler from KGP.
'forceSkipResolvedClasses' is wrong here, because nested class (`CC`)
won't be marked as cycle but the outer is.
Instead of this, we should check
canHaveLoopInSupertypesHierarchy recursively
```kotlin
open class C : <!CYCLIC_INHERITANCE_HIERARCHY!>D<!>() {
open class CC
}
open class D : <!CYCLIC_INHERITANCE_HIERARCHY!>C.CC<!>()
```
Also, this commit adds an optimization to avoid hierarchy search
for non-source classes (forceSkipResolvedClasses was introduced for this before)
For Compose libraries, it is important that libraries built with
K2 in version 2.0 can be read and used by a version 1.9 K1
compiler. That is not possible if custom function types are
in the metadata.
^KT-58456 Fixed
With this change it will have consistent naming with other compiler plugins.
'-embeddable' was also renamed.
'dist' should contain two identical jar files:
- 'serialization-compiler-plugin.jar'
- 'kotlinx-serialization-compiler-plugin.jar'
^KT-58530 In Progress
Swept and kept objects in NextFitPages are double counted; first in
GCApi::SweepObject and then again inside NextFitPage::Sweep. This fix
removes the latter.
Co-authored-by: Troels Lund <troels@google.com>
Merge-request: KOTLIN-MR-691
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
Both the new and old incremental compilation (IC) analysis rely on
Kotlin class metadata to detect a change.
However, Kotlin metadata currently doesn't contain info about
annotations (KT-57919), so the IC will not be able to detect a change
to them.
With this commit, we'll fix the new IC such that it can detect a change
to class annotations by not relying only on metadata.
We currently scope this fix to the new IC (cross-module analysis) first.
We'll fix this issue for within-module analysis later.
Performance: There seems to be no performance impact from this change.
Snapshotting the 400MB ideaIC-2022.1.4/app.jar takes 4.1s before and
after this change.
Test: Added ClasspathChangesComputerTest.testChangedAnnotations
^KT-58289: Fixed
JavaClassUseSiteMemberScope won't return a Java method getFoo if there
is an inherited Kotlin property foo in scope because calling this method
would effectively call the property accessor which is not possible in
Kotlin.
This commit excludes private properties from this consideration because
no accessor methods are generated for them, and so calling a Java method
getFoo is ok.
#KT-58577 Fixed
Evgeniy.Zhelenskiy