Move metadata extension with property order from kotlinx.serialization to core
After fix of KT-54792 properties will be deserialized in declaration order
if corresponding class was compiled with modern compiler. But this order
is needed for kotlinx.serialization for binaries compiled with any
kotlin compiler >= 1.4. Since we don't plan to add any extension points
into (de)serialization into FIR, we need to take into account existing
metadata extension from kotlinx.serialization in compiler itself
^KT-57769 Fixed
Add a special annotation @JsExternalInheritorsOnly for marking
external interfaces and classes. The marked interface or class
can’t be a parent for non external interfaces, classes or objects.
^KT-57423 Fixed
In K1 .isFun is always false for Java classes, so extra check
is added for that. This is not needed for K2, because .isFun is
true for all Java classes. Here it is not necessary to check
that interface has only one method, because such check will be
done in the place where interface implementation is created.
^KT-39362 Fixed
- An `OptionalAnnotationClassesProvider` only needs to be created if the
package part provider may even have optional annotation classes.
- In the IDE case, the package part provider never provides optional
annotation classes, so especially in the IDE, we can avoid a lot of
useless symbol providers with this.
- Dependency symbol providers contained a lot of useless
`FirExtensionSyntheticFunctionInterfaceProvider`s, because such a
provider only generates function classes from compiler plugins. If
there aren't any such `FunctionTypeKind`s in the session, there is no
need to even add the provider.
- `FirExtensionSyntheticFunctionInterfaceProvider`s that are added to
the list of dependency providers despite this optimization will now be
combined in `LLFirCombinedSyntheticFunctionSymbolProvider`. It checks
`ClassId` heuristics once, which is more efficient than checking them
in every provider separately.
See the comments in the code, but mostly the motivation is that once
it was decided to stick with such a legacy thing as raw types,
we are ok with some corner-cases hacks for them
(if there are not too many of them) and they don't break anything
when there are no raw types in the code.
^KT-56616 Fixed
Previously, we queried heavy kotlin package provider two times which affected performance
Now it's being queries only a single time
Also, the commit introduces separation for KotlinPackageProvider between kotlin and platform-specific packages
^KTIJ-24640
Annotation arguments that are resolved in COMPILER_REQUIRED_ANNOTATIONS
phase are resolved again in ANNOTATION_ARGUMENTS phase. If they resolve
to a different symbol, report an error.
KT-56177
This is required to be able to compile KGP and it's dependencies which
set LV to 1.4 when repo will use LV 1.9. This caused by the change how
enums are compiled (KT-48872).
There are cases when we have some indices in TypeRegistry left from
previous compilations, so registering new service may increase index
not by one
So such situation is possible:
First compilation (jvm project): register 20 different jvm services in
session + one from compiler plugin (with index 21)
Second compilation (common project): register only 10 common services in
session + one from compiler plugin (with index 21)
*numbers are imaginary
And in this situation increasing `ArrayMapImpl.data` size only one time
may not cover required index
^KT-56685 Fixed
Not fully initialized DeclarationDescriptor could leak to bindingTrace.
It is hard to detect the outcome of that kind of leakage due to
possibility to have not fully initialized instances if PCE happens in
the middle of publication and instance full initialization.
#KT-56364
#KT-56388
#KT-54085
#KT-55150
FunctionalTypeKind can be used in FE 1.0 too, so there is no need to
keep both classes. Also, removal of FunctionClassKind simplifies work
with FunctionalTypeKind in common code, like Analysis Api
Root cause:
Cached in ClassValue values are prohibited to reference any java.lang.Class or ClassValue instances as they are considered as strong roots that prevent Class and ClassValue garbage collection,
creating effectively unloadable cycle.
This problem is also known as JDK-8136353.
Actions taken:
* Extract anonymous ClassValue instance into a separate static class that does not capture anything implicitly
* Wrap cached values in ClassValue into SoftReference to avoid unloadable cycles
^KT-56093 Fixed
Resolver could be GCed if there is no any valid hard reference to it.
Some impl of PackageFragmentProvider (like DelegatingPackageFragmentProvider)
keep hard ref to resolver.
For the sake of investigation it is worth to know what kind of PFP is there.
#EA-725255
Merge-request: KT-MR-8581
Merged-by: Vladimir Dolzhenko <Vladimir.Dolzhenko@jetbrains.com>
Dmitriy Novozhilov