It acts as a workaround for the case when build tools or dependencies
are compiled with latest 'kotlin-stdlib' version, but at a runtime older
'kotlin-stdlib' is provided, which does not know about new
`EnumEntries`.
^KT-57317 Fixed
It is not enough to store evaluated constants only by
<startOffset, endOffset> pair. We need to consider case there constant
can be located in different files with the same offset but with
different values.
#KT-57928 Fixed
#KT-57929 Fixed
The issue is that during binding fake overrides, the compiler doesn't
differ setters from its properties, so the compiler uses the same
visibility for setter and entire property.
Changing logic at the binding stage can cause some unpredictable consequences so
the fix is to do this differentiation right at the reporting stage
^KT-56662 Fixed
Merge-request: KT-MR-9565
Merged-by: Michail Zarečenskij <Mikhail.Zarechenskiy@jetbrains.com>
- This change is a prerequisite for allowing combined Java symbol
providers (in LL FIR) to correctly disambiguate classpath order after
getting classes with a combined scope, as the index access of the
combined Java symbol provider is not guaranteed to return the class
that should be first based on the original dependency order. To be
able to disambiguate, a combined Java symbol provider needs access to
all class candidates the index can find.
- `FirJavaFacade.knownClassNamesInPackage` cannot be computed in the IDE
using the current strategy because there are multiple finders and
there is no `CliFinder`. However, the cache was still used, which
caused it to be filled with `null` values and additionally caused
worse performance in `JavaSymbolProvider` due to hash map accesses via
`hasTopLevelClassOf`.
- Rewriting the strategy is non-trivial as additional indices are needed
on the IDE side. See KTIJ-24642.
Add a special annotation @JsExternalTypeArgument for
marking function parameters. The marked parameter
accepts an argument with an external type only.
^KT-57479 Fixed
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
Yahor Berdnikau